Getting error : "fname lname could not be provisioned in SCIM Provisioner with SAML (Core Schema v1.1): Expected SCIM attribute '' to be an object" while configuring onelogin's SCIM app. I am able to see user info in response but still getting this error. Also where would I get SCIM Bearer Token?
Bearer token should come from the application you're trying to integrate with and that error usually comes from something in the return payload not being properly formatted or a required SCIM field (like id) not being returned at all.
I'd recommend contacting OneLogin developer support as these sorts of issues are a bit too complex to debug via Stack Overflow.
Related
I have a validate-jwt instruction in my APIM API policy (<inbound> section).
I am sending a hopefully correct token in a header and the request still fails.
What would be the way to find out from the APIM which specific JWT token validation check has failed?
I have figured out how to do the logging.
Enable Application Insights for APIM, set 100% sampling for your desired API and enable necessary flags (see Application Insights for APIM.
In the designated Application Insights instance, the JWT token issues are found if you query
exceptions
| where type contains "Token"
Note that type is different depending on what is wrong with the JWT token, but I am speculating that all relevant types might start with "Token..."
so you get something like
IDX10205: Issuer validation failed. Issuer: 'https://sts.windows.net/(abriged UUID)/'. Did not match: validationParameters.ValidIssuer: '' or validationParameters.ValidIssuers: 'https://login.microsoftonline.com/{tenantid}/v2.0'.
outerMethod
validate-jwt
Also, from App Insights' Application map one can click through to failed requests and drill down to exceptions arriving at similar log outputs.
Have you checked that the JWT is in fact valid? To do this you can paste the whole token value to https://jwt.ms in order to decode the token to see if you are missing any information.
If the token is valid, I would suggest setting up Application Insights for APIM if you haven't done that already and see if you can get any more relevant information from the logs there.
In regard to OpenID Connect and the MSAL library, what should the correct behaviour be if you request incorrect scopes, i.e. incorrectly spelt, or non-existent scopes?
We're testing this with Azure AD B2C and a React website using MSAL and when we try to acquire the token we simply get an empty result. Is this the correct behaviour or should we get an error?
In case an invalid scope is requested an Azure AD B2C error (such as AADB2C90117 or AADB2C90205) should be thrown. Sometimes immediately after hitting the authorize endpoint while others after credentials have been submited.
Ensure logging and error handling are properly set up.
I have an issue when trying to hit an endpoint in business central though a node application.
Using OAuth2 in postman I am able to get a desired response as seen below
This my configuration for Authorization:
but when trying to hit the same endpoint in Node using MSAL I get a 401 response.
This my configuration
I even tried taking the token generated by postman and inserted it into my application and was able to hit the endpoint with the desired response. I'm not sure what is missing from my application that's causing it to get a token that when used returns a 401 response.
What's missing from my application or is it something that I need to do in Azure or Business Central ?
I'm not an expert on Node, but I have used MSAL with PowerShell.
Getting the token through MSAL.PS (the PowerShell module for MSAL) you have to set the Scopes that you are requesting a token for.
In this case the scope should be https://api.businesscentral.dynamics.com/.default when you want to access the Business Central APIs.
I have set up an instance of Azure FHIR with an Azure FHIR proxy using this tutorial:
https://github.com/microsoft/health-architectures/tree/master/FHIR/FHIRProxy##configuration
I am unable to call the proxy without getting the following error message:
You do not have permission to view this directory or page.
I have created a token successfully using the following tutorial:
https://learn.microsoft.com/en-us/azure/healthcare-apis/access-fhir-postman-tutorial
I have created an app service principal in Azure with the permissions to access the FHIR proxy:
https://func-fhir-proxy-2.azurewebsites.net
I am generating the token using the following in postman:
Auth URL: https://login.microsoftonline.com/e34c8e67-182a-4085-9dc0-39a38dddea12/oauth2/authorize/?resource=https://func-fhir-proxy-2.azurewebsites.net
Access Token URL: https://login.microsoftonline.com/e34c8e67-182a-4085-9dc0-39a38dddea12/oauth2/token
Client ID: 4d138742-44c0-42cb-9878-8647a1d2ef17
Client Secret: Well..that's a secret!
Scope: openid profile
State: 12345
Postman returns 3 tokens: Access_token, Refresh_token, Id_token.
I have tried each token and all return the same 401 error.
ID token JWT looks like this:
I have tried calling the FHIR proxy API's, due to the tutorial I am not 100% which are the correct URLs:
https://func-fhir-proxy-2.azurewebsites.net/api/fhirproxy/Patient
https://fhir-test-apis.azurehealthcareapis.com/Patient/
None of this works, I just keep getting the same error. Does anyone know what I am doing wrong? Should I be calling the FHIR proxy API using the token? If so, why is the API not letting me in?
I managed to fix the issue. I found that the resource ID was needed in the auth URL:
This can be obtained from Enterprise Applications:
Also, creating two separate app registrations:
The link ending with ".../api/fhirproxy/Patient" is correct for the proxy deployment.
I'd suggest that you do a quick test that you can access the FHIR API without the proxy. You can use the existing deployment and follow instructions at https://learn.microsoft.com/en-us/azure/healthcare-apis/access-fhir-postman-tutorial.
Once you get that working, test the FHIR API with the proxy. You can start with the proxy that has the its security disabled (The FHIR api still requires security and you cannot disable it). Once you get that working, you can enable the proxy's security.
Since the proxy is a web app acting as a proxy, you will need two sets of credentials, one set for the FHIR api itself, which you specify in the proxy app, and one set for the proxy web app, which you specify in your client app, e.g. Postman or curl.
The reason for the error is actually very simple, you are using the wrong scope.
Usually the 401 error means that the audience of your token does not match your api. When you use the token to call the api, you will receive a 401 unauthorized error. The access token is issued based on the audience, so you must Make sure to set the scope to your api when you request the token. Of course you can also parse the token, check the aud claim, and make sure it is the api you want to call.
Therefore, according to your requirements, try to change the scope to: https://func-fhir-proxy-2.azurewebsites.net/.default
By the way, if you want to call api, you should use access token instead of refresh token and id token.
So I created an application in Azure AD a few days ago. When requesting authorization code, I am getting the following error back when I ask for both code and id_token (in response_type parameter):
AADSTS70007: 'query' is not a supported value of 'response_mode' when
requesting a token
Trace ID: xxxx-xxxx-xxxx-xxxx-xxxx
Correlation ID: xxxx-xxxx-xxxx-xxxx-xxxx
Timestamp: 2018-06-13 16:06:03Z
My request URL looks something like this:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code+id_token&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&nonce=1528906255418&state=12345
However, I don't get any errors if I only ask for code and not id_token. So essentially, following URL works:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&nonce=1528906255418&state=12345
What is even more interesting is that if I use a client id of an application created a few months ago, the code works perfectly fine and Azure AD returns me both code and id_token.
I did find one similar problem here: https://sharepoint.stackexchange.com/questions/242669/aadsts70007-query-is-not-a-supported-value-of-response-mode-when-requesting but there was no answer provided for that question.
I'm curious to know:
Why Azure AD does not throw any error for older application but for newer application? Has anything changed at the Azure AD level recently that will cause this problem? And that too for only newer applications.
Is there a way to prevent this error from happening? I would very much like to use query as response_mode instead of form_post.
Two different authorization flows:
If you want to use code + id_token in the response_type,you should be using OIDC Hybrid Flow.
However, if you just use codein the response_type, you should be using Authorization Code flow.
So, These two kinds of requests are different OIDC Authentication flow due to their different response_types.
Meanwhile, two different response_modes:
For form_post, form_post executes a POST containing the code to your redirect URI.When the Authorization Response is intended to be used only once, you should use form_post in reponse_mode. You can also see the details about form_post in this documentation.
For query, In this mode, Authorization Response parameters are encoded in the query string added to the redirect_uri when redirecting back to the Client. For more details about query in response_mode, you can refer to this documentation.
So, you may be more clear about the different response_mode for different Authorization flows.
For Authorization code flow, you can use query or form_post, For Hybird flow, you can use form_post or fragment. For web applications, we recommend using response_mode=form_post, to ensure the most secure transfer of tokens to your application. (the Microsoft OpenId Connect middleware only supports hybrid + form_post)
Why Azure AD does not throw any error for older application but for
newer application? Has anything changed at the Azure AD level recently
that will cause this problem? And that too for only newer
applications.
I'm not 100% sure, but AAD shouldn't change anything about its authorization/authentication level. Maybe you used different types of App or authentication flow.
Is there a way to prevent this error from happening? I would very much
like to use query as response_mode instead of form_post.
Since the reason is caused by OIDC framework, I think you cannot use query for hybird flow request.You'd better use form_post
in this flow if your app is a web app.
Additional, Azure portal is using this flow actually, but it may be a little different from what we can use. But you can see how the authentication/authorization works by catching its HTTP traffic via Fiddler. With this flow, you've to enable your App to allow implicit flow.
You can also see this sample for Authenticate using Azure AD and OpenID Connect Hybrid flow in this documentaion.
Adding an answer for the sake of completeness. Wayne's answer helped immensely!
So, instead of using response_type=query, I ended up using response_type=fragment and my new request URL now looks like the following:
https://login.microsoftonline.com/common/oauth2/authorize?resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_id=application-client-id&response_type=code+id_token&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=fragment&nonce=1528906255418&state=12345
And I was able to get both code and id_token back:
urn:ietf:wg:oauth:2.0:oob#code=code&id_token=id_token&state=12345&session_state=c6989d04-48ff-40cd-86ac-0cd2670ee168
Removed urn:ietf:wg:oauth:2.0:oob# and then parsed the remaining string to get both code and id_token values in the application.