Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get a SAML Assertion without another federated IDP #45071

Closed
keithdv opened this issue Dec 20, 2019 — with docs.microsoft.com · 41 comments
Closed

How to get a SAML Assertion without another federated IDP #45071

keithdv opened this issue Dec 20, 2019 — with docs.microsoft.com · 41 comments

Comments

Copy link

keithdv commented Dec 20, 2019

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.

@frankhu-2021
Copy link

@keithdv Thanks for your feedback! We will investigate and update as appropriate.

@souravmishra-msft
Copy link
Contributor

@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.

@umeshbarapatre
Copy link
Contributor

umeshbarapatre commented Dec 30, 2019 via email

Copy link
Author

keithdv commented Dec 30, 2019

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.

@umeshbarapatre
Copy link
Contributor

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.

@souravmishra-msft
Copy link
Contributor

souravmishra-msft commented Jan 2, 2020

@keithdv, Would like to check on this few points:

  1. What is the SAML request and the SAML response that you received from AzureAD?
  2. Have you just copied the assertion part (<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.

@souravmishra-msft
Copy link
Contributor

@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.

@umeshbarapatre
Copy link
Contributor

@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.

Copy link
Author

keithdv commented Jan 3, 2020

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.

@umeshbarapatre
Copy link
Contributor

umeshbarapatre commented Jan 3, 2020 via email

Copy link

Noirde commented Jan 5, 2020

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?

Copy link
Author

keithdv commented Jan 6, 2020

@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.

@umeshbarapatre
Copy link
Contributor

umeshbarapatre commented Jan 6, 2020 via email

@keithdv
Copy link
Author

keithdv commented Jan 6, 2020

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"> <Issuer>https://sts.windows.net/cb632b2c-217b-4edd-9be9-35f29b5c9f11/</Issuer> <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> </Assertion>

@Noirde
Copy link

Noirde commented Jan 7, 2020

Mine is slightly different. Especially the identity provider for me is not live.com, but also sts.../. Followed this tutorial - https://developers.sap.com/tutorials/cp-azure-ad-saml.html.

<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" > <Issuer>https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/</Issuer> <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="#_718927ef-7105-4baa-84c5-74b8b0b46600"> <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><Value></DigestValue> </Reference> </SignedInfo> <SignatureValue><Value></SignatureValue> <KeyInfo> <X509Data> <X509Certificate><Value></X509Certificate> </X509Data> </KeyInfo> </Signature> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"><Value></NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData InResponseTo="a883788fahf73ai48ee64e660g4fe8" NotOnOrAfter="2020-01-07T10:22:48.268Z" Recipient="<value>" /> </SubjectConfirmation> </Subject> <Conditions NotBefore="2020-01-07T09:17:48.268Z" NotOnOrAfter="2020-01-07T10:22:48.268Z" > <AudienceRestriction> <Audience>https://<Value>.authentication.eu10.hana.ondemand.com</Audience> </AudienceRestriction> </Conditions> <AttributeStatement> <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid"> <AttributeValue>32b337ff-9459-4bc1-b28a-b720735cbe39</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier"> <AttributeValue>113b9583-05a6-4867-90f2-1ab4d1ef7225</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider"> <AttributeValue>https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/</AttributeValue> </Attribute> <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences"> <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue> </Attribute> <Attribute Name="first_name"> <AttributeValue><Value></AttributeValue> </Attribute> <Attribute Name="last_name"> <AttributeValue><Value></AttributeValue> </Attribute> <Attribute Name="mail"> <AttributeValue><Value></AttributeValue> </Attribute> <Attribute Name="Groups"> <AttributeValue><Value></AttributeValue> </Attribute> </AttributeStatement> <AuthnStatement AuthnInstant="2020-01-07T09:22:46.413Z" SessionIndex="_718927ef-7105-4baa-84c5-74b8b0b46600" > <AuthnContext> <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion>

@umeshbarapatre
Copy link
Contributor

@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.

@umeshbarapatre
Copy link
Contributor

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

@Khyzdul
Copy link

Khyzdul commented Mar 23, 2020

@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.

@Khyzdul
Copy link

Khyzdul commented Apr 3, 2020

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:

https://support.secureauth.com/hc/en-us/articles/360019646672-O365-Error-Message-AADSTS50107-Requested-federation-realm-object-does-not-exist

imply the Issuer needs to appear in the output of this command?

@keithdv
Copy link
Author

keithdv commented Apr 9, 2020

@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.

Copy link

@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")

@umeshbarapatre
Copy link
Contributor

@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

@wimvanhouts
Copy link

@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...

Copy link

@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.

@Khyzdul
Copy link

Khyzdul commented May 7, 2020 via email

@michaelwolz
Copy link

michaelwolz commented Jul 8, 2020

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.

@mmacy
Copy link
Contributor

mmacy commented Jul 16, 2020

#reassign:paulgarn @paulgarn Cc:@hpsin

@PRMerger6 PRMerger6 assigned paulgarn and unassigned umeshbarapatre Jul 16, 2020
@PRMerger6
Copy link
Contributor

GitHub user umeshbarapatre has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

@krish-gh krish-gh changed the title How to get a SAML Assertion without ADFS How to get a SAML Assertion without another federated IDP Jul 30, 2020
@krish-gh
Copy link
Contributor

Redirecting the issue #59746 here.
CC: @amit17051980

@amit17051980
Copy link

Thanks Krish.
I'm eagerly waiting for a solution!

@krish-gh
Copy link
Contributor

krish-gh commented Aug 3, 2020

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.

@krish-gh
Copy link
Contributor

krish-gh commented Aug 3, 2020

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 krish-gh closed this as completed Aug 3, 2020
@keithdv
Copy link
Author

keithdv commented Aug 3, 2020

@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

@keithdv
Copy link
Author

keithdv commented Aug 3, 2020

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

@krish-gh krish-gh reopened this Aug 3, 2020
@krish-gh
Copy link
Contributor

krish-gh commented Aug 3, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests