Closed keithdv closed 4 years ago
@keithdv Thanks for your feedback! We will investigate and update as appropriate.
@keithdv, I apologize for the delay in my response. I did check the thread and would really like to understand some more details about why are we trying to get a SAML assertion generated from the same IDP from where we plan to fetch the token.
I would rather go for the Authorization Code Grant flow of OAuth2.0 and get the access token. I am not really sure if this is supposed to work even.
I have tested this flow with ADFS and it works fine. Do let me know if you would like to get the steps for the same, so that I can share it with you.
Also, feel free to let me know if there is a certain requirement/restriction based on which you plan to follow the route you mentioned in your query, so that armed with a better understanding on your actual requirement, we can research more and share some more useful information.
Hi Keith,
To get a SAML assertion, you would need to have a IDP i.e identity provider federated with Azure active directory. I tested this with ADFS and one more third party identity provider. Any IDP which supports SAML 2.0 tokens should work with this. Hope this helps !
Thanks Umesh
From: Keith Voels [mailto:notifications@github.com] Sent: 21 December 2019 02:44 To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Umesh B umesh.barapatre@hotmail.com; Mention mention@noreply.github.com Subject: [MicrosoftDocs/azure-docs] How to get a SAML Assertion without ADFS (#45071)
I am trying to get a SAML Assertion but I have a simple Microsoft Azure account using my MSDN credits - no ADFS - and would like to try this. I can get a SAML Response using the login.microsoft.com/_TenantId/SAML2?SAMLRequest API but when I put the SAML Response as the 'assertion' in the call to 'OAuth2/v2.0/Token' I get an error everytime: AADSTS50107: The requested federation realm object 'https://sts.windows.net/_TenantID_/' does not exist.' How do you get a SAML Assertion without ADFS?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWIKJA5AXT7NQUZAORTQZUYRTA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ICCC32A, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKCNYWOJY4YS73T4J7OTRWDQZUYRTANCNFSM4J6CXN2Q.
Version 1.0 (oauth/token) does this. "SAML assertions obtained with an OAuth2.0 OBO flow" https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow#saml-assertions-obtained-with-an-oauth20-obo-flow For anyone else...I would ignore this article and see the above link.
Hi Keith,
Can you help me with on which scenario you want to fetch the SAML assertion. The SAML bearer assertion flow works with a valid OAuth token to be presented to any IDP to provide a SAML assertion on basis of the same. The concept is similar with the other platforms like SAP and salesforce. OBO flow is for a different reason and I would like to have some more details on what is the end objective.
@keithdv, Would like to check on this few points:
<assertion>....</assertion>
) from the SAML Response and then URL Encoded it before feeding the response to the Token Endpoint of AAD?Do let me know the answers for the following queries along with end objective as requested by @umeshbarapatre so that we can help you better.
@keithdv, Had some interesting facts regarding this scenario. This process is supposed to only work with Federated domains and not with a Managed domain, as the response shared by IDP (in case of a managed domain) is not trusted by that same IDP because the managed domain in not a part of the Azure Trusted domain list. In the Azure's Trusted Domain List only the federated domains are part of.
Hope this helps.
@souravmishra-msft - yes that is correct. SAML bearer assertion flow is for federated domains unlike managed domain. Hence, I asked for what are we trying to achieve here with this test.
Here is what we need. Our application is calling an Azure AD registered and protected API. That Azure API is then calling an SAP registered and protected API. SAP is federated to Azure AD. We do not want the application to be aware of SAP or call SAP directly. So we need to do a token exchange within the Azure API: exchange the Azure bearer token to a SAP bearer token while retaining the identity. Since two service providers (Azure and SAP) are involved we cannot exchange OAuth2 tokens we need to exchange SAML Tokens – a SAML assertion. This in an API so it cannot be a browser functionality. The v1 endpoint support this very well. You can send the Azure API’s Access Token to ‘oauth/token’ and get a SAML Assertion back. We then send the SAML Assertion to SAP and get the access token required to call the SAP API (see link below). We need a ‘grant_type:jwt-bearer’ to ‘token-type:saml2’ in V2 like exists today in V1. https://wiki.scn.sap.com/wiki/display/Security/Using+OAuth+2.0+from+a+Web+Application+with+SAML+Bearer+Assertion+Flow I am not alone please see the comments: https://answers.sap.com/questions/12852835/sso-using-azure-ad-and-sap-netweaver.html I have read thru all of Microsoft documentation and have never seen any discussion around “Managed Domains” vs “Federated Domains”. I don’t know what “Managed Domain” refers to.
Well this is exactly what we wanted to know. This article was also published when we tested with the same SAP scenario and the SAP article that you mentioned while doing the POC. The only difference is that in that scenario AAD as well as SAP has been federated with a third party IDP viz ADFS but it can be any other IDP. And hence this suggested to call ADFS endpoint to fetch the SAML assertion. In your case AAD is acting as First party IDP and you are calling AAD oAuth endpoint v1 to get the saml assertion(We can test and update this as a comment though). Once you get the SAML assertion then you present the same to the SAP oAuth token endpoint to fetch a SAP Oauth token and call whatever required api from SAP side too. So in a nutshell the bearer flow remains the same. However, I will check the V1 comment to get that updated. This does not mean that AAD can only work as IDP and rest of the world also used lot of other IDP even if ADFS is going to be legacy. There are lot of other 3rd party idp which many companies uses like Oracle IDM, Vmware IDM etc. Hope this information helps !
Thanks Umesh
From: Keith Voels [mailto:notifications@github.com] Sent: 03 January 2020 22:21 To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Umesh B umesh.barapatre@hotmail.com; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] How to get a SAML Assertion without ADFS (#45071)
Here is what we need. Our application is calling an Azure AD registered and protected API. That Azure API is then calling an SAP registered and protected API. SAP is federated to Azure AD. We do not want the application to be aware of SAP or call SAP directly. So we need to do a token exchange within the Azure API: exchange the Azure bearer token to a SAP bearer token while retaining the identity. Since two service providers (Azure and SAP) are involved we cannot exchange OAuth2 tokens we need to exchange SAML Tokens – a SAML assertion. This in an API so it cannot be a browser functionality. The v1 endpoint support this very well. You can send the Azure API’s Access Token to ‘oauth/token’ and get a SAML Assertion back. We then send the SAML Assertion to SAP and get the access token required to call the SAP API (see link below). We need a ‘grant_type:jwt-bearer’ to ‘token-type:saml2’ in V2 like exists today in V1. https://wiki.scn.sap.com/wiki/display/Security/Using+OAuth+2.0+from+a+Web+Application+with+SAML+Bearer+Assertion+Flow I am not alone please see the comments: https://answers.sap.com/questions/12852835/sso-using-azure-ad-and-sap-netweaver.html I have read thru all of Microsoft documentation and have never seen any discussion around “Managed Domains” vs “Federated Domains”. I don’t know what “Managed Domain” refers to.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWLXEV5ME6XAZFPST6TQ35UJDA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBR5VQ#issuecomment-570629846, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKCNYWJUJ7FN6NV43FM2D2DQ35UJDANCNFSM4J6CXN2Q.
Excuse me, but the explanations here have not really made me any smarter. I'm a bit up in the air right now, so it would be great if someone would explain a little bit more about what needs to be done.
I have set up SSO between Azure Active Directory and SAP Cloud Platform. After logging on to the SAP Cloud Platform via Azure AD I get a SAML response. I encrypt the assertion part of the SAML response with BASE64. I then send this to the token endpoint (v2). There I also get the error message 'AADSTS50107: The requested federation realm object 'https://sts.windows.net/_TenantID_/' does not exist'.
Has a solution been found for this? Or are we basically doing something completely wrong?
@noirde you are close. You are on the same path I am on. I have not actually gotten to try the Azure SAML Assertion with SAP in my enterprise I am waiting for access. Once I do I fear I will have the same error. You get that same error when you try to use the SAML Assertion with Microsoft Graph. See the closed comments on the error. One I have permissions I will let you know if we succeed or not.
Hi Keith,
Can you share the sample assertion envelope you are receiving when making a call to azure v1 end point. Is that a samlp envelope assertion ?
Thanks Umesh
From: Keith Voels [mailto:notifications@github.com] Sent: 06 January 2020 08:58 To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Umesh B umesh.barapatre@hotmail.com; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] How to get a SAML Assertion without ADFS (#45071)
@Noirdehttps://github.com/Noirde you are close. You are on the same path I am on. I have not actually gotten to try the Azure SAML Assertion with SAP in my enterprise I am waiting for access. Once I do I fear I will have the same error. You get that same error when you try to use the SAML Assertion with Microsoft Graph. See the closed comments on the error. One I have permissions I will let you know if we succeed or not.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWMSMKAXIUX3T2CF7BTQ4KQNDA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEJYAI#issuecomment-570989569, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKCNYWOPER7HLDULIQQHV63Q4KQNDANCNFSM4J6CXN2Q.
Hi Umesh,
Here you go. I don't believe so. It's simply <Assertion>
`<Assertion ID="_32e7b830-43cf-40cd-a0f7-0ddf851dfb00" IssueInstant="2020-01-06T22:03:57.551Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_32e7b830-43cf-40cd-a0f7-0ddf851dfb00">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>Ng1WJ0mjixtBOAflWvZUX10duf7bmjHV7DGIyQDiABs=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>BbHkH/aXuejrSDoWHuBXbXWVyF8aU1O1ZMtCaJwgvrvjBjuA8Go9P7y+maryiQXk0+o/6jv5GciNkYaatAcIl8XpHetUvs6VRtEbqleE0n80LY/eSV7fDmhRYnq7YlH/d3lEmMInsEE2q0WxX/9hxvpADlTt6x1zF7QvCSmQl5nlBEvYuPXqhKgLNtCbBykwu+CHHfcP+ULBJZkZJp12wbV00yPJxlrOYSvszKLmvwaBqWNqxjmuKUADNnHnbHZWr2UbsuBiBn2fIOTg6AFhl7JktI/vMMr35wJJkJTDWvq8CknJxFHxGKUspCGHtI0nNOCUhBaiCw3q4LcKylpOlw==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIDBTCCAe2gAwIBAgIQMCJcgWf4l5xPpeoEwB7DKDANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTE5MTExNTAwMDAwMFoXDTI0MTExNDAwMDAwMFowLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANF4YcKZhKTfowwWqZ84RW7bxFNgaSy3Gi85V5uJpU9jMCmZV0VFGptryNFEQ1GESmmuDutgQlkkhjr9ixkOrTA+aFPg6pLn+OG6NYS7nyKgAC1MprLH0bq06y3dH6lQPWQhd3wPP+8UIua9+9JuIfhu9Xs/HhN5cYlT5cEniV0aWuUMxgPAKcG1xolfupYhlOHjFwVN/QOaxcuk3YqGguD+sZ7PiHcJSzFnTkdvD+DtMoW1U6nDf5FuDeAEKJ7JQf7RjiRoViYxZHKrEPHG4iZ+kOhV6DQA16ISTt7ALXVB8gTTF3OvItubk2E3v6sgirgtvdE5Mkd4MTJcO67bgdUCAwEAAaMhMB8wHQYDVR0OBBYEFEXiTeLGkA2LgAjQOrT2KChpgwCgMA0GCSqGSIb3DQEBCwUAA4IBAQA6GqtYZDQzym0yxfL2NnlSbJP/lLhSQOqbPBdN6DWQ/3duk+e08Ix5qy63hzW+qQR0PAkFEcooL5+bdheS66tFJpVejEcqCSKUVvwOUe6GY/ju752dlB7anBB9An362khehCxqydYNS5Igl0rtcP7dKC3ZBn1m2B9ULsyx46iNpfHQHHv9NKU2vVq2CtNc95CFktwjUwlyWMgbfI/DzPX/cC6KnglqsuVVBO7+jIaBmi0XGqudooZkqgIrvnfNMM13Gy78TUNHsCiAQEwZ/L17yNbzotNGxAoPfuXldbD52MQNOsA7WhH+j8qFWY6gZzTN4NpVtuW4m04TCEFexnTz</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ftOmbYBIMVgi3RWFQa2lLAqkmtzBAdZXJjrcQVo5KR0</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
</Subject>
<Conditions NotBefore="2020-01-06T21:58:57.207Z" NotOnOrAfter="2020-01-06T23:03:27.207Z">
<AudienceRestriction>
<Audience>https://ebs.sap.com/sap/bc/sec/oauth2/token</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>cb632b2c-217b-4edd-9be9-35f29b5c9f11</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>af56d9be-a146-4230-801e-f83f1a3bab4e</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Voels</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>Keith</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
<AttributeValue>Keith Voels</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>live.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2020-01-06T22:03:07.208Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
`
Mine is slightly different. Especially the identity provider for me is not live.com, but also sts.../
` <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_718927ef-7105-4baa-84c5-74b8b0b46600" IssueInstant="2020-01-07T09:22:48.487Z" Version="2.0"
https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/ https:// .authentication.eu10.hana.ondemand.com 32b337ff-9459-4bc1-b28a-b720735cbe39 113b9583-05a6-4867-90f2-1ab4d1ef7225 https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/ http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password ` urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Thanks Keith .couple of questions. Is this assertion accepted at sap oauth token . I could not see name Id may be I am reading it From mobile device but that’s one of The mandatory attribute. Let me know if we can connect sometime
Get Outlook for iOShttps://aka.ms/o0ukef
From: Keith Voels notifications@github.com Sent: Tuesday, January 7, 2020 3:39:53 AM To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Umesh B umesh.barapatre@hotmail.com; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] How to get a SAML Assertion without ADFS (#45071)
Hi Umesh,
Here you go. I don't believe so. It's simply
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWICCZVPVAWOMG5QTI3Q4OT3DA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIG6VLA#issuecomment-571337388, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKCNYWN7ATHP2NQHI3NUYHTQ4OT3DANCNFSM4J6CXN2Q.
Regarding Keith post there's
I guess Keith is doing something quite similiar to me, but somehow against the v1 and not the v2. For testing I took the assertion I got back after successfully logging into SAP Cloud Platform via Azure AD. I transformed it into base64 via https://www.base64encode.org/ manually.
Now I'm trying to post to "https://login.microsoftonline.com/{{TenantID}}/oauth2/v2.0/token" with the body:
grant_type:urn:ietf:params:oauth:grant-type:saml2-bearer client_id:{{ClientID}} client_secret:{{ClientSecret}} scope:https://graph.microsoft.com/.default assertion:{{Base64_encoded_assertion}}
Now I'm getting the forementioned error:
{ "error": "invalid_request", "error_description": "AADSTS50107: The requested federation realm object 'https://sts.windows.net/<tenantId>/' does not exist.\r\nTrace ID: 6365a830-7aa3-4b27-94cc-7b3d31d09a00\r\nCorrelation ID: 5f89f618-58d2-4f4a-9e90-fcf3d7ca6762\r\nTimestamp: 2020-01-10 17:24:49Z", "error_codes": [ 50107 ], "timestamp": "2020-01-10 17:24:49Z", "trace_id": "6365a830-7aa3-4b27-94cc-7b3d31d09a00", "correlation_id": "5f89f618-58d2-4f4a-9e90-fcf3d7ca6762", "error_uri": "https://login.microsoftonline.com/error?code=50107" }
@noirde I have ran into that error multiple times and have not gotten around it. I cannot get Microsoft Graph to accept a SAML Assertion to get an access token in any senario.
@umeshbarapatre Yes, we've gotten SAP to accept the SAML Assertion. We've had to play with the NameID attribute , AudienceRestriction and Recipient within the Azure Enterprise Application settings but we got it to work.
Yes, I'd like very much to connect. Please send me an email. Thanks!
Any updates or further hints?
Hi Keith,
Apologies but I got a little busy with day to day responsibilities. Which timezone are you working with. We can connect over skype on Tuesday 4th feb sometime.
Thanks Umesh
From: Keith Voels [mailto:notifications@github.com] Sent: 21 January 2020 03:14 To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Umesh B umesh.barapatre@hotmail.com; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] How to get a SAML Assertion without ADFS (#45071)
@Noirdehttps://github.com/Noirde I have ran into that error multiple times and have not gotten around it. I cannot get Microsoft Graph to accept a SAML Assertion to get an access token in any senario.
@umeshbarapatrehttps://github.com/umeshbarapatre Yes, we've gotten SAP to accept the SAML Assertion. We've had to play with the NameID attribute , AudienceRestriction and Recipient within the Azure Enterprise Application settings but we got it to work.
Yes, I'd like very much to connect. Please send me an email. Thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWOEA27GFBJVMY62W5TQ6YLKPA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJN4FIA#issuecomment-576438944, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKCNYWMYS3GU3G5LFK3URCLQ6YLKPANCNFSM4J6CXN2Q.
Were you able to deduct a solution?
@keithdv - That's good to hear that NameID and other attributes worked for you. W.r.t Graph API , if you can tell which graph api you are using, then probably I can share my views which can be helpful.
Were you able to deduct a solution?
@Noirde - As Keith confirmed the SAML assertion is successful, we are one step ahead, I can help with Graph API acceptance based on information provided
@umeshbarapatre - I have a different authorization scenario and I am trying to determine if I can use SAML Assertion to OAuth2 bearer token flow or if this thread is saying it won't work. In my case I am using SAML2 SSO to 3rd party app with AzureAD as the IdP… this is working, but I want to get an OAUTH bearer token to call Microsoft graph (same tenant as AzureAD) to integrate 3rd party app to Office 365. I am still working on the test but this thread has me confused as to whether this should/should not work. Any help is appreciated.
So, I have gotten to the point that the SAML Assertion issued by Azure AD is accepted by login.microsoftonline.com/tenant-id/OAuth2/v2.0/token however I get the same error you are getting:
AADSTS50107: The requested federation realm object 'https://sts.windows.net/tenant-id/' does not exist.
I am asking for the following grant-type: 'urn:ietf:params:oauth:grant-type:saml2-bearer' to access the Graph API in the same realm as the SAML Assertion.
When I run this query on our tenant from powershell: Get-MsolDomainFederationSettings the result is empty.
Several vendor articles such as this one from SecureAuth:
imply the Issuer needs to appear in the output of this command?
@Khyzdul I never got the Microsoft Graph API to accept a SAML Assertion as documented. I got stuck at the error you are at. Within Azure stick with OAuth2 tokens.
What we did accomplish is other vendors (MuleSoft, SAP) will accept the Azure SAML Assertion to get user specific OAuth2 bearer tokens.
To me this is logical. OAuth2 is not meant to involve more then one Identity providers. SAML is; that's it's role. So when jumping identity providers use an SAML assertion. Within a single identity provider don't use SAML Assertions.
@keithdv Though it is true what you say about the difference in SAML and OAuth2, there are however two other aspects I think. One is the fact that SAML is used for some older legacy systems that do not yet implement the OAuth in the back (and then it would be nice to be able to reuse this part and use the assertion for other things), and, second (and more important imho), one would/could assume that when asking a SAML assertion from "an AAD tenant" and then getting a token later on from the same AAD tenant would not require any federation whatsoever? I understand the technical reason why we get this error, but from a user/logical point of view, it doesn't make much sense... wouldn't you agree? (now it is basically saying "we do not trust our own domains")
@Khyzdul - May i know if there is a specific need to go with SAML route in your case. I understand you are federated against Azure only. you can directly call the OAuth token endpoint to get a token unless there is anything i am missing
@Khyzdul it is primarily a matter of "what we already have". We have a fairly large product which already has SAML Integrated for the login procedure, and works with AAD.
However, another (new) module/extension/plug-in needs to access the MS Graph SDK and we can give it the assertion, but it actually needs to "exchange" this for a token (this is not visible for the user then) and call the Graph function. This is not possible now, because the AAD that comes with the O365 and does SAML cannot turn it into a token because of the error that the Realm is not known (even thought it's the same AAD).
So now you can indeed argue that we could rewrite the whole login procedure with OAuth, but, that 's a reasonable amount of work in a legacy product. This has impact on the product because up until now, it was only a module that needed to change, and now suddenly it becomes a serious product change, to work around something that is from user point of view definitly a "bug". Thus impact on the roadmap, QA cycles, releases, etc...
@keithdv We have exactly the same requirement, get SAML assertion from AAD, use it to send to SAP for an access token and call the SAP API using the access token. I have read tons of document and still I cannot make it to work. From the comments above, it seems that yours is working now. Is it possible that you can share the steps? Thank you very much.
We tested our theory that we needed to register our tenant as a trusted federation realm with itself (did this in a non-production tenant). The resulting error message indicated we had to set the tenant authorization mode to federation.
Our conclusion at this point is we will have set the tenant to a mode where it is expecting it's authentication to be handled by an external IdP. Not knowing what the side-effect might be for things like O365, we're not pursuing this further. We're re-writing the app to use Oauth.
I am baffled at the logic of supporting SAML SSO (using Azure AD as the IdP), if Azure AD won't trust the assertions it issues.
It would be helpful if MS published an Azure AD SSO guide illustrating the patterns they support and clearly calling out the assumptions/limitations of each. For example, if you use SAML with Azure AD as the IdP, you cannot use the session to call the graph api because token exchange is not supported.
Seems to be a reason to completely avoid using Azure AD as a SAML IdP.
Thanks for the engaging conversation.
Get Outlook for Androidhttps://aka.ms/ghei36
From: dominic1904 notifications@github.com Sent: Wednesday, May 6, 2020 7:55:13 AM To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Khyzdul ellis854@live.ca; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] How to get a SAML Assertion without ADFS (#45071)
@keithdvhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeithdv&data=02%7C01%7C%7Ce4937829995f44b2fc3108d7f1b4566f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637243629152039847&sdata=SSCEzWzXsqKX4DeDTAVKZ4VEK5AoUsjXo4Wu8LF%2BnTM%3D&reserved=0 We have exactly the same requirement, get SAML assertion from AAD, use it to send to SAP for an access token and call the SAP API using the access token. I have read tons of document and still I cannot make it to work. From the comments above, it seems that yours is working now. Is it possible that you can share the steps? Thank you very much.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F45071%23issuecomment-624605575&data=02%7C01%7C%7Ce4937829995f44b2fc3108d7f1b4566f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637243629152049843&sdata=8jUZhFplYEqm5mKPusLYAqtZxY4p3gMyMjHYQs7tSQM%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAO5BDHYDRYGUG735YX7JQG3RQFF2DANCNFSM4J6CXN2Q&data=02%7C01%7C%7Ce4937829995f44b2fc3108d7f1b4566f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637243629152049843&sdata=Xzy8%2F7HUCgMjDJgKSdhyPqifGxI%2BS3Jes2GSbOEHwPU%3D&reserved=0.
Are there any updates on this topic?
I am in the exact same situation. I registered an SAP C4C Enterprise Application in AAD and am able to use it successfully for Single Sign On to SAP.
In addition, I want to use the exact same AAD app to request a SAML assertion from AAD and use it as a OAuth SAML bearer to request an access token from SAP. As @keithdv mentioned in the beginning of this issue, I also am able to receive a SAML assertion from the login.microsoft.com/_TenantId/SAML2
endpoint but I have absolutely no clue how I can influence the Recipient
of the SubjectConfirmation
in the SAML response to match the desired SAP token endpoint: .../sap/bc/sec/oauth2/token
.
To clarify my situation:
I have a client that should be able to perform requests to a private SAP API. Therefore, users should login in to their AAD which already has a trust relation to their SAP. From this point on, I would like to receive a SAML assertion from AD with the token endpoint of SAP as the recipient
which I can then use with my other OAuth App credentials from SAP to get an access token. I am still not sure if this is even possible with Azure due to all the different statements in this issue and different other sources mentioned here? I would really appreciate any advice on this.
GitHub user umeshbarapatre has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.
Redirecting the issue #59746 here. CC: @amit17051980
Thanks Krish. I'm eagerly waiting for a solution!
It is confirmed from product team that yes, this exchange is specifically for federated users where the application gets a SAML token from ADFS or another federated IDP. There are no plans to add further functionality at this point in time.
In most cases this scenario (where the user is an AAD user and the SAML token you have is issued from AAD with the application as Audience) can be satisfied by a regular auth code flow. Simply get an auth code from AAD and request an access token for graph from the token endpoint. Since the user is already signed in (in order to get the SAML token). SSO kicks in and no reauthentication is required from the user. The end result is the same.
We will proceed to close this issue now. Please feel free to comment here if there is any follow up question or issue.
@krish-gh So there is not plan to add functionality that is in v1.0 of the token endpoint (link below)?? Again this is CRITICAL to our work flow to communicate with SAP and Salesforce and we will be in big trouble if this functionality is dropped. We are already in the service layer many physical layers beyond the browser.
Version 1.0 (oauth/token) does this. "SAML assertions obtained with an OAuth2.0 OBO flow" https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow#saml-assertions-obtained-with-an-oauth20-obo-flow
Here's a diagram of what we need to accomplish. We are the integration API team - we cannot ask the browser application to make changes. In fact we don't want them to address if it even SAP fulfilling the request. Again, we can do this with OAuth2 v1.0 token endpoint. SAP OBO.pdf
@keithdv please continue with v1.0 in your OBO SAML assertion part of the API workflow. There is no plan to drop it from v1.
As mentioned there is no immediate plan to add this in V2 as of yet. We will keep a tag on the demand of such scenario. Thank you very much for sharing the details of your workflow.
I am trying to get a SAML Assertion but I have a simple Microsoft Azure account using my MSDN credits - no ADFS - and would like to try this. I can get a SAML Response using the login.microsoft.com/_TenantId/SAML2?SAMLRequest API but when I put the SAML Response as the 'assertion' in the call to 'OAuth2/v2.0/Token' I get an error everytime: AADSTS50107: The requested federation realm object 'https://sts.windows.net/_TenantID_/' does not exist.' How do you get a SAML Assertion without ADFS?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.