0

Im calling a REST api from an azure B2C custom policy, what this flow will do is call out to one endpoint with a GET and if I dont get back the claim information I need, it will call out to another end point with a POST. There are two limitations i'm seeing in azure B2C that I wanted to see if anyone had a work around for.

For the GET call, it uses the oid from the claim in the url path (I.E api/info/{oid}). From what im seeing from the docs, I dont believe there is a way to dynamically populate the service url with the OID from the claim. Is there any workaround to this?

For the POST call, I am hitting APIM and need headers for both an API key and a Subscription Key. As far as im aware, B2C will only allow the post call with a single header (unless doing basic auth) when calling out. Is there a way to send both headers when making the call?

The goal is to make these calls without changing the current paradigm of the api(I.E. Changing path variable to query params etc).

wes4455
  • 35
  • 1
  • 4

1 Answers1

0

For the GET call, you can use the SendClaimsIn Metadata, set to Url. Then you just use a token for every InputClaim you specify in the technical porofile.

https://learn.microsoft.com/en-us/azure/active-directory-b2c/restful-technical-profile#metadata

For the POST call, I would think you could supply two cryptographic keys to send both your API key and Subscription Key. I haven't had a chance to verify this, but I would think it would include both in the Header. I will try and test this with an Azure Function at some point, unless you're able to validate beforehand.

Example of each challenge:

<Metadata>
  <Item Key="ServiceUrl">https://www.website.com/api/info/{objectId}</Item>
  <Item Key="AuthenticationType">ApiKeyHeader</Item>
  <Item Key="SendClaimsIn">Url</Item>
</Metadata>
<CryptographicKeys>
  <Key Id="X-Api-Key" StorageReferenceId="B2C_1A_ApiKey"/>
  <Key Id="X-Subscription-Key" StorageReferenceId="B2C_1A_SubscriptionKey"/>
</CryptographicKeys>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="objectId"/>
</InputClaims>
Dharman
  • 30,962
  • 25
  • 85
  • 135
Brad C.
  • 564
  • 3
  • 5
  • Ive tried sending both using that method and while the upload accepts it, it fails when running the user flow, unless something else was going on, let me know if you find success and I will give it a try – wes4455 Feb 05 '21 at 15:55
  • What does “it fails” mean? – Jas Suri - MSFT Feb 06 '21 at 00:07
  • The flow does not complete, and uploading my signup-sign in policy throws the error: Policy "X" in tenant "Y" contains multiple cryptographic keys where only one is expected. – wes4455 Feb 07 '21 at 16:57
  • 1
    As for path variables, this answer solved it entirely. For custom headers, we went with the decision to send the subscription key as a query param, and only pass the secret key as a header. I will mark this response as a solved answer as it did help me come to a full solution. – wes4455 Feb 09 '21 at 16:12
  • @wes4455 your comment looks interesting, could you share how you managed to pass the secret from Policy Keys as a query param, an example of how you achieved this when you cannot pass it through `CryptographicKeys`? Thanks. – lbartolic Jun 11 '21 at 11:14
  • So sorry for such a late response, we simply added it to the ServiceUrl param statically, so it would be something along the lines of YourURL.com/path / {variable}/?subscription-key=aketvalue123456 Im sure there are clever ways to inject an input claim to achieve the same result, but this was much simpler – wes4455 Apr 28 '22 at 18:50