While testing with Azure AD, I can successfully send SAML LogoutRequests to the SingleSignOnService URL endpoint with HTTP-POST binding.
However, Azure AD explains here that LogoutRequests should be sent to the SingleLogoutService URL endpoint instead, with HTTP-REDIRECT binding.
How is it possible that it works when sending LogoutRequests to SingleSignOnService endpoint ? It works well, but is it recommended ?
Related
I am looking into a Node.JS API that has authentication through Azure AD, which all seems to be working ok, when i pass access token generated by logging into the web app, it authenticates and returns data.
However i now need the API to access MSGraph to retrieve Profile Photo etc. Ho do i pass authentication to MSGraph, i believe the accesstoken is different isnt it because they are different scopes. So how do i generate a new accesstoken for MSGrpah after i have logged into my app.
API endpoint just queries a db of users returning a JSON response, but i want to append the users profile image in base64Image to the response.
How do i do this
Thanks
You could use On-Behalf-Of flow, the OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API.
Sample:
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=2846f71b-a7a4-4987-bab3-760035b2f389
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE0OTM5MjA5MTYsIm5iZiI6MTQ5MzkyMDkxNiwiZXhwIjoxNDkzOTI0ODE2LCJhaW8iOiJBU1FBMi84REFBQUFnZm8vNk9CR0NaaFV2NjJ6MFFYSEZKR0VVYUIwRUlIV3NhcGducndMMnVrPSIsIm5hbWUiOiJOYXZ5YSBDYW51bWFsbGEiLCJvaWQiOiJkNWU5NzljNy0zZDJkLTQyYWYtOGYzMC03MjdkZDRjMmQzODMiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJuYWNhbnVtYUBtaWNyb3NvZnQuY29tIiwic3ViIjoiZ1Q5a1FMN2hXRUpUUGg1OWJlX1l5dVZNRDFOTEdiREJFWFRhbEQzU3FZYyIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInV0aSI6IjN5U3F4UHJweUVPd0ZsTWFFMU1PQUEiLCJ2ZXIiOiIyLjAifQ.TPPJSvpNCSCyUeIiKQoLMixN1-M-Y5U0QxtxVkpepjyoWNG0i49YFAJC6ADdCs5nJXr6f-ozIRuaiPzy29yRUOdSz_8KqG42luCyC1c951HyeDgqUJSz91Ku150D9kP5B9-2R-jgCerD_VVuxXUdkuPFEl3VEADC_1qkGBiIg0AyLLbz7DTMp5DvmbC09DhrQQiouHQGFSk2TPmksqHm3-b3RgeNM1rJmpLThis2ZWBEIPx662pjxL6NJDmV08cPVIcGX4KkFo54Z3rfwiYg4YssiUc4w-w3NJUBQhnzfTl4_Mtq2d7cVlul9uDzras091vFy32tWkrpa970UvdVfQ
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of
I have a saml response that gives me azure active directory when doing the process with saml 2.0, the whole process is done normally, I send a saml request and the azure active directory returns the saml response, to do the whole process I have based on this guide, I've been reading a bit and I've noticed that Azure AD in the saml response sends the values within this tag:
<xenc:CipherData>
<xenc:CipherValue>VALUE HERE</xenc:CipherValue
</xenc:CipherData>
And not inside:
<AttributeStatement><Attribute Name="IDPEmail"><AttributeValue>administrator#contoso.com</AttributeValue></Attribute></AttributeStatement>
as specified in the documentation. The question is, how to get the true values that azure active directory is sent to me and not these encoded values, I am using Python 3 and Google App Engine, in addition to mentioning azure active directory and saml 2.0 to do the login process, I leave the SAML response complete in this url in case it serves to give a better context to my question.
As mentioned above, the SAML response you are getting is encrypted. Specifically Azure is encrypting its assertions (including the ones you are looking for) inside an encrypted body called CipherData.
You have two options:
1 - Disable SAML response encryption.
Azure AD calls SAML response encryption as SAML token encryption which is a bit confusing. You can follow this guide to disable the response. You must have uploaded an encryption public key/cert before.
2 - Configure your service provider to supported encrypted SAML responses.
The SAML token is encrypted.
You need to get the client side certificate used for this and use that to decrypt it.
How do I hand RelayState correctly to Okta-side ACS URLs so that it gets to the IdP as entered?
The Okta-provided ACS URLs for Identity Providers don't handle SP-initiated RelayState as I expect.
I put ?RelayState=hello on an ACS URL and the IdP gets a SAMLRequest with a RelayState of %3FRelayState%3Dhello which decodes to ?RelayState=hello.
If I put ?RelayState= instead then the RelayState with the SAMLRequest is blank as I expect.
I've attached NetworkData.xml which is a capture from Internet Explorer. On line 447 column 53, you can see that the RelayState encoded by Okta to be POSTed to https://fs.research.verafin.local/adfs/ls includes ?RelayState in it.
AD FS's IdP SSO service at https://fs.research.verafin.local/adfs/ls decodes and re-encodes the RelayState preserving the broken value it was given and drops it into a form to be POSTed to https://verafin.oktapreview.com:443/sso/saml2/0oaa25fc86YRTkyb60h7 (Okta ACS URL).
It then redirects to https://verafin.oktapreview.com/?RelayState=hello&fromLogin=true HTTP/1.1
Is this a bug in Okta's ACS implementation?
How do I get Okta ACS URLs to accept RelayState in GET requests (SP initiated SSO with RelayState)?
Steps to Reproduce
Copy the ACS URL from an Identity Provider in Okta
Paste it into the browser with ?RelayState=hello after it
Visit resulting URL
How do I hand RelayState correctly to Okta-side ACS URLs so that it gets to the IdP as entered?
The accepted answer is no longer current, Okta recommends against using fromURI now and recommends using SAML DeepLinks as defined here
Redirect with SAML deep links
Use SAML deep links to automatically redirect the user to an app after
successfully authenticating with a third-party IdP. To use deep links,
assemble these three parts into a URL:
SP ACS URL
For example: https://{myOktaDomain}.com/sso/saml2/:idpId
The app to which the user is automatically redirected after successfully authenticating with the IdP
For example: /app/:app-location/:appId/sso/saml
Optionally, if the app is an outbound SAML app, you can specify the relayState passed to it.
For example: ?RelayState=:anyUrlEncodedValue
The deep link for the above three parts is:
https://{myOktaDomain}.com/sso/saml2/:idpId/app/:app-location/:appId/sso/saml?RelayState=:anyUrlEncodedValue
You can use fromURI as a query parameter with a minor tweak.
An example with minimal dependencies is a loopback within an Okta Org.
Say you want to get to the admin interface of an Org. It's at:
/home/admin-entry
URL encoded (what you need for RelayState) that is:
%2Fhome%2Fadmin-entry
You can verify this by looking at the URL of the Admin link on the /app/UserHome page.
You create a Identity Provider called loopback in Okta. My example has an ACS URL of:
https://dev-971545.oktapreview.com/auth/saml20/loopback
You create an App that is linked to that Identity Provider called loopback. It has a Single Sign-on URL (visible after clicking View Setup Instructions on the Sign-on tab) of:
https://dev-971545.oktapreview.com/app/independentconsultantdev927755_loopback_1/exkadbfail8okn4W80h7/sso/saml
There are two layers of RelayState:
The app you want Okta to direct you to: in this case the loopback app
The path within that app
Passing the RelayState to an App SSO URL is easy:
https://dev-971545.oktapreview.com/app/independentconsultantdev927755_loopback_1/exkadbfail8okn4W80h7/sso/saml?RelayState=%2Fhome%2Fadmin-entry
Following that URL brings me to the Admin dashboard.
There's no inbound SAML yet. This is all within Okta. Let's add the SAML layer.
The path of that App SSO URL, minus the leading slash (workaround for fromURI) is:
app/independentconsultantdev927755_loopback_1/exkadbfail8okn4W80h7/sso/saml?RelayState=%2Fhome%2Fadmin-entry
We URL encode that to prepare it to be the value of a query parameter:
app%2Findependentconsultantdev927755_loopback_1%2Fexkadbfail8okn4W80h7%2Fsso%2Fsaml%3FRelayState%3D%252Fhome%252Fadmin-entry
You then drop that insanity on the ACS of the loopback Identity Provider as the fromURI query parameter:
https://dev-971545.oktapreview.com/auth/saml20/loopback?fromURI=app%2Findependentconsultantdev927755_loopback_1%2Fexkadbfail8okn4W80h7%2Fsso%2Fsaml%3FRelayState%3D%252Fhome%252Fadmin-entry
You can convince yourself that worked or you can open the Network tab of your browser's developer tools and trace the communications. The ACS drops a RelayState prepending the slash (that's why we had to remove it), then gets redirected to the IdP (the loopback App), then gets reflected back to the ACS (preserving the RelayState). Login completes and Okta redirects to the loopback App SSO URL with the RelayState in the query parameter. Okta processes that and redirects to itself and then redirects to the embedded RelayState which takes you to the Admin Dashboard.
This is a working example of Deep Linking from SP-initiated flow from Okta with Okta as a SAML intermediary to another app.
The SAML Response will be posted to the following url:
https://domain/sp/ACS.SAML2
But when I try to hit the url, I am not able to see the response.
Anything wrong in my approach?
Thanks & Regards,
Aswini J
A few things assuming you are setting up SAML 2.0 Web SSO Profile -
What do you mean you can't "see" the Response? Are you successfully logging into the IDP and having it redirect the Browser to the PF ACS URL?
With PingFederate, the application and protocol end-points are case sensitive. You should use http(s)://www.server.com:<PF runtime port>/sp/ACS.saml2. If you simply request this value from your browser with a GET request and no SAML data, PingFed will show you a generic error template page.
If you have successfully POST'd the SAMLResponse to the right endpoint, you will see the actual SAMLResponse logged in the /pingfederate/log/server.log.
We have an OpenSSO (OpenAM) instance set up at our end to work as a Service Provider (SP). It's been working well so far in an SP Initiated SSO scenario, however, I recently had to set it up for an IDP initiated scenario and am unable to get it to work successfully. To explain, in this scenario, the IDP would like to send the SAMLResponse directly to the Assertion consumer service at my end and our OpenAM instance should be able successfully digest the response and send the user to our underlying application. My questions are:
Is there any other configuration required in this scenario except for exchanging/uploading the metadata between the IDP and us (SP)?
Can I upload the metadata of the iDP in the same COT as the other IDPs that are currently working in the SP Initiate Scenario? Or should there be a new COT for each IDP provider?
What URL should I provide to the IDP to send the SAMLResponse to? Is it the AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" from our metadata? I tried this a few days back and OpenAM reported an error - "this is not the right consumer service for this request" or something.
I got an answer for this on an OpenAM forum -
http://lists.forgerock.org/pipermail/openam/2012-August/007872.html