I'm trying to set up the following workflow:
User logs into app A.
App A bounces off a central simpleSAML instance to create a session.
User accesses app B.
App B bounces to the central simpleSAML instance to check for a session.
If a session exists, the user is returned to app B with their attributes and is authenticated on app B. This bit works.
If a session does not exist, the user should be returned to app B without a login attempt on the central instance. This bit does not work.
Is there a simpleSAML endpoint that could do this? I'm looking for a getSession or similar.
The desired setting is isPassive. Example:
$auth_source = new \SimpleSAML_Auth_Simple('source_name');
$auth_source->requireAuth(array('isPassive' => true));
With the standard SimpleSAML IDP, this request will be authenticated as normal if the user is logged in on the IDP. If the user isn't, a SimpleSAML_Error_NoPassive error will be returned. It's up to the SP to deal with this.
Related
I am implementing a SSO using SimpleSAMLPhp Service Provider.
I provided my metadata to remote Shibboleth Identity Provider and was provided a test account.
When a user visits a specific page on my SP, they get redirected to the IdP, login, and are redirected back to my web site with a bunch of IdP provided attributes. This part works.
This part I am struggling with.
If the user authenticates with the same IdP through a different Service Provider and then visits my page, how do I know they are already authenticated? Currently I am being asked to login again.
Is there a configuration value somewhere that lets me do this? Or am I using the wrong method? This is what I am doing.
$as = new SimpleSAML_Auth_Simple({REMOTE_AUTHSOURCE});
$as->requireAuth(); // this redirects to remote IdP login
$attributes = $as->getAttributes();
Thanks.
There are two separate authentication sessions to consider. One session is in you app and the other is at the IdP. The requireAuth method can tell if the user already has an authenticated session in your application, and will return immediately in that case.
There is no way for you to tell if a browser has a session at the IdP. You just call requireAuth whichs send the user there and if the IdP decides the user's session is still valid it will respond without prompting for login.
Are you saying that the user has a valid session at the IdP and they are being re-prompted to authenticate when you send the user there? That could be due to IdP policy, or if your app was sending something like 'forceAuth' in its AuthnRequest.
Is there a way I can persist my application specific claims added to the identity after it gets authenticated by Identity Server. I don't want to load the claims from database for the user and add everytime I want to access my API.
The best practice for these cases is Claims transformation.
You can add more claims to token after user authenticated with IdentityServer and redirected to you client.
I am new to WIF.
And now I encountered a problem when performing single sign off.
The following is the background of my problem:
First of all, I am working on two old application A and B, which they stores the user's information in their own session variable after authenticating a user. And App A and B have their own local database. Now, my work is to use ADFS to enable SSO (Single Sign On) between two applications.
Now, I create a new active directory to store the users centrally.
When a user try to login application A through ADFS, application A need to check the user name in the claim is exist in the local database. If exists, the user can login to App A. Otherwise, App A will reject the claim.
Here is the technical part:
I extend the WSFederationAuthenticationModule and check the incoming claim with the local database in the method OnSessionSecurityTokenCreated. If the result is matched, I retrieve the user information from local database and store it in the session variable (so that i can minimized the code change). App B uses the same approach.
I am happy with the SSO from here. But the problem come when i perform single sign off:
When I logout from App A, i first clean up the own session in App A and call the WSFederationAuthenticationModule.FederatedSignOut method. However, App B do not clean up its own session. I suppose the OnSignedOut in WSFederationAuthenticationModule will be invoked. How can i clean up the App B's session when App A is signed out?
It may be very confusing. Please leave any comments if you find something unclear or need further explanation.
Signout in WS-Fed is implemented by ADFS (it asks for a gif with app/?wa=wsignoutcleanup1.0), not only locally. That is the only way to notify the other app.
Your app has to to redirect to ADFS with a signouturl. Then both apps will be notified and can cleanup their session state (with the gif request).
I am reading about SAML2.0 based federation as it is supposed to apply for SSO in the current setting:
In application A a user has credentials email/password1
In application B, the same user has credentials username/password2
If the user logs in at A, he/she should also be logged in at B
SAML v2.0 seems to be a good choice in this situation:
central identity provider (IdP), maybe A or B or a third party C.
A and B would be service providers (SP)
if user tries to access A, A would request SAML assertions from the IdP containing email
if user tries to access B, B would request SAML assertions from the IdP containing username
But if the user is authenticated in A, how should he/she be logged in B (for which username)?
Documents about SAML (e.g. here: https://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf) pretend that SAML allows SSO without requiring to synchronize or migrate identities between all players.
However, I don't see, how all this should work without maintaining and merging all credentials of the same subject in the central IdP which in fact is a kind of synchronization.
If you have the impression that I am quite confused about SAML v2.0 capibilities, you are right ;-)
As a service provider, SAML doesn't allow you to do away with a user store usually. This is because it's a method by which you externalize authentication only. Most service providers have a 1-to-1 relationship of users in their store, to users at their identity providers. However, it may not need to be this way, as you can do a one-to-many federation as well. I'll expand shortly.
In the one-to-one, you will generally use either a "just in time" provisioning method, or an out of band user synchronization method. The just in time is usually done via attributes provided in the assertion, and is done by the SP when it realizes that the user that has been presented in the assertion doesn't exist the application's user store. The out of band method is some other process, a directory synchronization, etc. A user gets add to the IdP's store, and some process adds that user to the SP store, via flat file, XML, etc.
Having said that, depending on the type of service provider, you could do a one-to-many, and count solely on the attributes provided to support the needs of the application. Let's say you run a printing operation. You could agree on having the IdP send a cost center along with other attributes for the user (name, number, email, etc.). Then all the data is stored just on that print job, with the Cost Center sent back during billing. I will say, I've only seen a couple of instances of one-to-many federations in my career.
I don't think your example is quite right - meaning you didn't ask it quite right, but then again, you're not familiar enough, maybe.
Let's presume the following:
Service Provider X needs username
Service Provider Y needs email
Identity Provider A can provide all of these from their user store
The user shows up at SPX. SPX says "based on the url you went to (idpa.serviceproviderx.com), I know you need to be sent over to IdPA." and redirects the user to IdPA. IdPA authenticates the user, looks at its "attribute contract" to determine that it's supposed to send username to SPX, and redirects the user with that attribute as its "subject" in the assertion. SPX consumes that assertion, and can map the user back to where they are supposed to go.
Now, the user is browsing through their portal, and clicks a link that starts an SSO to SPY. The user is already authenticated to IdPA, so IdPA checks it's contract and sees it's supposed to use email with SPY. It creates an assertion for SPY with email as the subject, and redirects the user to SPY for consumption of the assertion and connection to the application.
Now, in both those instances, the IdP has to determine what to send to complete the contract with the SP - and it always will. This is based on a "contract" - some form of agreement between the IdP and SP that has to be supported by administrators of both systems.
Ok, I think the main missunderstanding here is how authentication works in SAML. I SAML the IDP authenticates the user. This means, you have no crederial store at the SP.
SSO in SAML happends at the IDP. If the user has already signed in once at the IDP the user is just sent back to the SP without authenticating.
I am integrating against a CAS server. User logs into there, gets forwarded to a script which does the CAS validation, gets the User and logs them in. This all works fine.
Part of the spec for the integration is to ensure we ping the CAS server every 60 seconds, to ensure the user does not get logged out at the 'parent' CAS server, as they are still active.
Is there something built into the CAS setup for this purpose? I've been looking through the CAS documentation and the phpCAS client to no avail. There's a renewAuthentication method but it causes the user to have to login again when called. Perhaps this is just a configuraton issue at the server side though?
There is no way for you to ping the CAS server on behalf of the user as your application should not have access to the token identifying the user's session. The default policies automatically extend the user's single sign on session every time the user requests a new service ticket from the CAS server.
However, if you do have the TGT (which you really, really, really should avoid), you can basically request a service ticket for the user, and that would extend the life of the single sign on session (though if you did this, you would not need to do it every 60 seconds, as that's rather extreme).