I was recently reading this blog post about chaining multiple ADFS STS together: http://blogs.technet.com/b/dmitrii/archive/2012/08/18/chaining-multiple-sts.aspx
In case the link goes dead, the author describes chaining together multiple ADFS instances to give a set-up like:
Claims enabled app
Relying partner STS - fs1.external.com
Replying partner STS - fs2.contoso.com
IdP STS - fs1.contoso.com
When a user logged into the claims enabled app, they would hit each STS and eventually the IdP where they would get authenticated. At that point the authentication is passed back through the different STS to the user.
In this scenario, is the domain of each STS authenticated? I.e. is a cookie issued for fs1.external.com, fs2.external.com, fs1.contoso.com or just the IdP domain (fs1.contoso.com)?
Just the IDP domain.
Note however, that on the downstream path:
each ADFS can augment the token with claims
the token is re-minted
and signed with the signing key for that instance
Related
When an user account is disabled on a connected IdP, how do I ensure the account is blocked as soon as possible on Keycloak? At the moment, the “disabled” user is able to continue using my SPA because Keycloak continues to refresh the access token without speaking to the external IdP.
One of the critical features required by my partners when using SSO is that they have control over their users’ access to my application. At the moment if the user was logged into my SPA, they can continue using it for about 24 hours. I would hope to cut that time down to 5 minutes, the lifetime of the access token.
The external IdP is Google. I have tried using both Keycloak’s builtin Social provider for Google as well as setting up a SAML app in Google and user-defind SAML provider in Keycloak. I’m using Keycloak v9 but can upgrade if necessary.
Is there a recipe to achieve my goal? What options do I need to set in the Keycloak client and SAML provider?
Many thanks!
The approach could be as follows. The resource server will need to do the checking with the IDP, not Keycloak.
Enable the option to Store Tokens and Read Stored Tokens in the IDP settings.
Assign users the broker/read-tokens role.
On the resource server, decide on a frequency to check whether the user has been disabled on the IDP. Be aware of each IDP's token introspection's endpoint. Each time the API is consumed:
First of course verify the access token as usual.
If it's time to verify against the IDP, call the Keycloak API with the access token to retrieve the IDP's access token.
The Keycloak endpoint is: https://{domain}/realms/{realm}/broker/{idpid}/token
Call the IDP's token introspection endpoint to validate the IDP access token.
Act accordingly if the IDP responds that the token is not valid. Respond with 401 and ensure that the Keycloak access token can't be used again. Maybe the end_session_endpoint or revocation_endpoint, not sure.
Token validation endpoints:
Google: https://www.googleapis.com/oauth2/v3/tokeninfo?access_token={access_token}
AuthO: https://{tenant}.eu.auth0.com/userinfo
MS Azure: doesn't exist, good luck with that!
I have created a SAML 2.0 App on okta and have finished all the configurations. I then attempt to do an authorization from my application, by doing a redirect to the okta idp ->
http://www.okta.com/(okta created token)?SAMLRequest=(encoded saml xml)
The redirect returns a 404. When I go to my admin okta console I don't see any logs for the failed attempt, which i guess makes sense since it is returning a 404, but i don't know how to figure out what is causing the 404.
Is there a way to figure out what is causing the issue?
Install SAML tracer browser extensions and try it again to confirm the SAML Response is being decoded correctly.
To address your question "Is there a way to figure out what is causing the issue?", I have repeated your SAML 2.0 authentication steps suggested by your post.
The following responses and answer will help you to "figure out what is causing the issue".
(1) Quote your post "I have created a SAML 2.0 App on okta and have finished all the configurations. I then attempt to do an authorization from my application, by doing a redirect to the okta idp ->
http://www.okta.com/(okta created token)?SAMLRequest=(encoded saml xml)"
Response:
(I) I have created a SAML 2.0 SP App on okta and have finished all the configurations as you did.
(II) I then attempt to do an authorization from my SAML SP application, by doing a redirect to the okta idp as you did.
(III) Submit the username/password of local Okta user account (e.g., john.doe#example.com) to proceed with SAML authentication.
(2) Quote your post "The redirect returns a 404. When I go to my admin okta console I don't see any logs for the failed attempt, which i guess makes sense since it is returning a 404, but i don't know how to figure out what is causing the 404."
Response:
(I) In my experiment, the redirect returns the following error message instead of a 404 error.
Sorry, you can't access SAML 2.0 SP demo because you are not assigned this app in Okta.
If you're wondering why this is happening, please contact your administrator.
If it's any consolation, we can take you to your Okta home page.
(II) Then "I go to my admin okta console" as suggested by your post,
navigate to Reports > System Log, I saw the log below.
Event Info Targets
User attempted unauthorized access to app SAML 2.0 SP demo (AppInstance)
FAILURE :
(3) Quote your question "Is there a way to figure out what is causing the issue?"
Answer:
I summarize the four (4) potential root causes of your SAML authentication failure. The top #1 potential root cause is that you uploaded the wrong okta IdP metadata file into your SAML 2.0 SP app server (see the detailed description below).
(I) Potential Issue #1:
The root cause of my issue is that my local okta user account was NOT assigned to access this SAML 2.0 App.
Resolution:
(a) Navigate to Applications > SAML 2.0 App, then click Assign > Assign to People,
(b) On the pop-up dialog box, select the local Okta user accounts (e.g., John Doe (john.doe#example.com)), click Assign, click Save and Go Back, then click Done.
(c) Repeated the above SAML 2.0 authentication steps again, I was redirected back and logged in to SAML 2.0 App successfully.
(II) Potential Issue #2:
Three (3) potential root causes of this issue are that
(a) you did NOT fill in all the correct SAML SP information of your SAML 2.0 SP app on okta.
(b) or you did NOT upload the okta IdP metadata file into your SAML 2.0 SP app server
(c) or you uploaded the wrong okta IdP metadata file into your SAML 2.0 SP app server (this is the highest probability for bringing your 404 failure, because unlike most of SAML IdPs which create only one IdP metadata file for all SAML SP apps, okta create different IdP metadata files for different SAML SP apps).
Resolution:
Regarding to root cause (II.a): You need to ensure that the following SAML SP information should be the exactly the same as the SAML SP metadata of your SAML 2.0 SP app when you create new SAML 2.0 app.
Single sign on URL should come from your SAML SP metadata, e.g.,
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-saml-sp-app-URL/SAML2/POST" index="1"/>
Audience URI (SP Entity ID) should also come from your SAML SP metadata, e.g.,
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_random-string" entityID="https://your-saml-sp-app-URL/SAML2/Metadata">)
The sample SAML Settings of SAML 2.0 SP app on okta
Navigate to Applications > your SAML 2.0 App > general > SAML Settings
Single Sign On URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Recipient URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Destination URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Audience Restriction https://your-saml-sp-app-URL/SAML2/Metadata (i.e., your SAML SP entity ID)
Default Relay State
Name ID Format Unspecified
Response Signed
Assertion Signature Signed
Signature Algorithm RSA_SHA256
Digest Algorithm SHA256
Assertion Encryption Unencrypted
SAML Single Logout Disabled
authnContextClassRef PasswordProtectedTransport
Honor Force Authentication Yes
SAML Issuer ID http://www.okta.com/${org.externalKey}
Regarding to root causes (II.b) and (II.c): You need to upload the correct okta IdP metadata into your SAML 2.0 SP app server.
Note that okta creates different okta IdP metadata files for your different SAML 2.0 SP apps.
Navigate to Applications > your SAML 2.0 App > Sign On
Identity Provider metadata is available if this application supports dynamic configuration.
Click Identity Provider metadata to download the okta IdP metadata for your SAML 2.0 SP app.
Log in to your SAML 2.0 SP app, upload the okta IdP metadata into your SAML 2.0 SP app, and then complete the configuration to store the okta IdP information on your SAML 2.0 SP app server.
I have a situation, wherein, I have integrated, WSO2APIM, Identity Server, Microsoft ADFS2.0. Configured successfully so that MSADFS is acting as IdP, APIM acting as SP (with /publisher) as a service. Configuration worked fine when accessed(/publisher of APIM), ADFS presented LogonPage, all necessary SAML2.0 exchanges happened perfect and final page (/publisher) presented.
Now, the actual situation is, instead of accessing APIM service (/publisher), I need to access a POST Rest URL(Eg. APIMIP:Port/vendors/payments). This API is configured to hit backend API (Eg. BEIP:Port/vendors/payments).
1. In above situation, I need to pass the SAML authentication information or any other authorized info to actual BE, somehow.
2. How to achieve it.
Scenario:
1) Browser(User) requests resource from Service Provider (SP).
2) SP Redirects (with SAML Request) to Identity Provider (IdP).
3) Since it is first login, User gives the (IdP) his/her valid credentials.
4) IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
After creation of user, If I try to authenticate it works as expected
but when I change user data on idp, and try after cleaning complete
browser data in any of browser (firefox, chrome) it shows only old
assertion data in SAML response on the way to idp to sp.
Even I have deleted user on idp and created again with same email id
with different user data it shows only old user data in SAML response.
There is nothing exist on browser side even cleaned cached data ,
cookies, and re-installed browser too.
I have gone through : Are SAML tokens cache/stored anywhere on the browser?
Not helped.
I there any settings on idp (OpenAM) side to resolve it? (I have unchecked Disable Federation persistence if NameID Format is unspecified:)
idp: OpenAM-12.0.0, sp: redmine SAML ominiauth
So what I miss here, I don't get it.
I got a solution by exploring the stuff at OpenAM side.
There is no issue with SAML plugin. It is OpenAM which cached SAML assertion attributes so every time it takes old assertion with SAML response.
To resolve issue need to follow below steps in OpenAM:
1) Select Federation-Select SP (from entity provider list)-Assertion content
-Check "Disable Federation persistence if NameID Format is unspecified:"
2) If above case won't work then follow this process:
-Select configuration-Servers and Sites-Default Server Settings:
-Add following properties:
-com.sun.identity.idm.cache.entry.expire.enabled=true
-com.sun.identity.idm.cache.entry.user.expire.time=10
-com.sun.identity.idm.cache.entry.default.expire.time=10
My knowledge of these systems is not large so please forgive me if I am asking dumb questions.
I hope to achieve the following:
Idp (AD FS 2.0) -> SAML 2.0 -> Sp (simpleSAMLphp)
*I don't need anything more fancy than to simply authenticate a user.
I have attempted to configure Windows Server 2008 with AD FS 2.0 (domain A) as an Identity provider and have it handle authentication requests from a service provider on a different domain (created using simpleSAMLphp (domain B)).
The AD FS 2.0 Management application allows me to add raw meta XML from the SP to configure the idp. And my SP has the facility to do the same. So I figure that If I setup the idp (AD FS 2.0) correctly then I will simple just have to make the SP interpret the metadata of the idp.
Currently I feel that I am close to a solution (but then again I am probably wrong!). Currently it seems everything is find right up to the point when the Idp asks for your login credentials, and I enter my credentials, it appears that the session has started, but I get a 'Not Authorized - HTTP Error 401. The requested resource requires user authentication.' message after entering the correct login credentials.
Could someone please explain how to fix this? or if it's quicker a step by step setup to make AD FS 2.0 authenticate using SAML 2.0 for simply authenticating a username and password.
Thankyou in advance for any hints!
Have you established a claims provider trust within ADFS 2.0 management? Your system needs to accept claims-bearing tokens from a trusted claims provider. That is, whatever STS -- "Security Token Service" -- you have in front of your user repository. ADFS can both a "Relying Party" -- RP -- or a STS. You need both a relying party and a STS.
Check out Eugenio Pace's MSDN blog for more details:
http://blogs.msdn.com/b/eugeniop/archive/tags/federated+identity/