AADSTS50107: Requested federation realm object 'https://sts.windows.net/xxxxxxxxxxxxxx' does not exist error is coming while calling the token api with assertion token

[amarnathprofisssional]

I have followed with the continuation of below link.
#37742

While calling the token api call, we are getting below error.

{"error":"invalid_request","error_description":"AADSTS50107: Requested federation realm object 'https://sts.windows.net/xxxxxxxxxxxxxxxxxx/' does not exist.\r\nTrace ID: 61e097a6-dfa7-4869-b573-ea8e0ec25100\r\nCorrelation ID: 73372794-eaee-45f0-b599-3f8d9a138ac7\r\nTimestamp: 2019-09-30 20:03:53Z","error_codes":[50107],"timestamp":"2019-09-30 20:03:53Z","trace_id":"61e097a6-dfa7-4869-b573-ea8e0ec25100","correlation_id":"73372794-eaee-45f0-b599-3f8d9a138ac7","error_uri":"https://login.microsoftonline.com/error?code=50107"}

I have provided the request as specified with the assertion token i.e., base64 encoded that I am getting from saml response.

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-saml-bearer-assertion

#37742

Can you please help me on this.

Thanks

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 9f168986-8f8f-4e97-cba8-547564c97eb5
• Version Independent ID: 12ac4571-4f35-300e-9119-8d13673f3722
• Content: Microsoft identity platform and SAML bearer assertion flow
• Content Source: articles/active-directory/develop/v2-saml-bearer-assertion.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @umeshbarapatre
• Microsoft Alias: ryanwi

[souravmishra-msft]

@amarnathprofisssional, Thank you for your query. We will investigate and update this thread.

[souravmishra-msft]

@amarnathprofisssional, Can you please share the URL for the token endpoint that you are using?
The token endpoint should be "https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token" .

[amarnathprofisssional]

@souravmishra-msft
Below is the url which I am using.

https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/oauth2/v2.0/token

But, I am still facing same issue

[souravmishra-msft]

@amarnathprofisssional,

This issue occurs for one of the following reasons:

The Issuance Transform rule is required to change the issuer from the default Active Directory Federation Service (AD FS) instance host name to the issuer set if the domain that's federated is missing.
The Issuance Transform rule is not updated after you add child domains.
This issue occurs when multiple top-level domains are federated to the same AD FS instance for tenants.

Check the steps mentioned in the following article and let us know if that helped.

[amarnathprofisssional]

@souravmishra-msft

I have few questions.

1. Do we need to this configuration ever after we get saml response?

My assumption is that since we are already getting the saml response that means there is no issue with the configurations.

Correct me if I am wrong?

2. In the specified link we have few commands which we need to check right. They have mentioned saying to check in powershell, will this work in azure cloud as well?
   We are planing to maintain with the cloud system so want to check whether it will support cloud based system and what need to be done for it?

[amarnathprofisssional]

Hi any update on this?

[souravmishra-msft]

@amarnathprofisssional, Few parts of the SAML response totally depends on what is specified in the SAML assertion, that you are sending to the ADFS server. By that I mean, the following tags:

1. <a:To s:mustUnderstand="1">
2. <o:Username>
3. <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
4. <a:Address>

Now based on the values in these tags,the user name and password is validated by ADFS and then it looks for the "<a:Address>" tag to understand for which Relying Party in ADFS this SAML assertion is sent for. After identifying the same, ADFS issues the claims to that RP based on the claims configured in for that RP and prepares the SAML response for the application to be consumed.

Now looking into the actual error message AADSTS50107 and description and also looked into the back-end data based on the correlation Id and timestamp from that error and found that what you are sending in the request, doesnt match what is configured in your RPs identifier field.

The entry in the identifiers filed of the RP [in this case O365's RP], should match up with entry in the <a:Address> tag in the SAML assertion that you are sending.

Coming to the second question, Connect-MSOLService is a legacy cmdlet and that is not supported by the Cloud shell. Hence you will have to install the module on a normal powershell and then use it. We recommend installing the MSOLService module on the ADFS server and execute the commands from there.

Hope this helps.

[souravmishra-msft]

@amarnathprofisssional, I just wanted to check with you if there are any more queries around this question. Do let us know, so that we can proceed accordingly.

[amarnathprofisssional]

@souravmishra-msft

Thanks for the details.
Let me check and get back to you guys.

[souravmishra-msft]

@amarnathprofisssional, I just wanted to check with you if there are any more queries around this question. Do let us know, so that we can proceed accordingly.

[amarnathprofisssional]

@souravmishra-msft

we are still checking and we will come back to you once done.

[souravmishra-msft]

@amarnathprofisssional, We are closing this thread as of now. Please feel free to re-open this thread in case you need any further help on the same.

[tihomirbg]

Hello, I faced to the same response error:
{
"error": "invalid_request",
"error_description": "AADSTS50107: The requested federation realm object 'https://sts.windows.net/xxxxxxxx does not exist.\r\nTrace ID: 38fc0835-db2d-4b19-9a15-2a28a6045300\r\nCorrelation ID: 6a2e2b35-ff9a-47bc-bd60-dc466f2ee4bf\r\nTimestamp: 2020-08-20 15:37:27Z",
"error_codes": [
50107
],
"timestamp": "2020-08-20 15:37:27Z",
"trace_id": "38fc0835-db2d-4b19-9a15-2a28a6045300",
"correlation_id": "6a2e2b35-ff9a-47bc-bd60-dc466f2ee4bf",
"error_uri": "https://login.microsoftonline.com/error?code=50107"
}

I successfully set up SSO between Azure Active Directory and Laravel App.

After SSO login I get Response with attributes, SAML assertion base64 encoded, and etc..

My POST request

Url:
https://login.microsoftonline.com/xxxxx/oauth2/v2.0/token

Body:
grant_type = urn:ietf:params:oauth:grant-type:saml2-bearer
client_id = xxxxxxx
client_secret = xxxxxxx
assertion= SAML response from SSO login (PHNhbWxwOlJlc3Bvb.....)
scope = openid https://graph.microsoft.com/.default

Just for test deflated SAML response and saw that response is <samlp:Response ID="xxxx" Version="2.0" ....

Also try deflating the SAML response and picking only the SAML assertion element from the SAML response and then pass it to the /token endpoint after encoding it back but faced to same response error.

Is there a way to get it working ?
Thanks

[hksfho]

Hi @tihomirbg. Have you fixed it? I am also facing this issue...

[tihomirbg]

Hi, unfortunately not. You can not use this SAML response. After SSO you can use Auth Code Grant to retrieve access token.
The key is session cookie. When you logging user with SAML you generate a session cookie. After that when Graph API invokes an OAuth flow you use the session cookie to authenticate. Actually you need 2 apps in https://portal.azure.com/.
One enterprise app for SSO and one in App registrations for OAuth(Auth Code Grant).

[elrapha]

@tihomirbg Can you explain further with an example how one will do this? Which endpoints does one use...how does one set the session cookie. A postman example would be helpful. Thanks

I am facing same issue

[GianlucaVagnoni]

Any update on this thread?