I am using SAML based SSO for my application where IDP role is played by OpenAM. I have tested SP based SSO,SLO and IDP based SSO, all are working fine, but IDP based SLO is not working, when a user is logging out of IDP, I am getting a notification in my SP, but this request do not contain any user information or browser cookies, so wondering about two things:
Is these notification happening back channeled?
If not, how can I fetch my SP side session and invalidate when such notification comes?
also if their some sample implementation available in Java?
the request flow depends on the profile being used / configured ... see SAML profile spec section 4.4.
It's up to the SP how the SLO is handled, e.g. Spring Security based SAML SP has a bug where the local session is not clean up correctly (if you use this see my workaround on Spring JIRA).
Related
I have two service providers set up with one IdP and users are required to be authenticated twice to access both services at the same time. From my point of view, this is not "SSO" and I am thinking that there might have been settings done incorrectly and I would like to see if the community here can provide me with directions and/or possible solutions.
Just a thought - the behaviour for the authentication on each service looks valid as I understand that IdP is required to send signed SAML assertions to the providers in order to access the services. However, because I only have one IdP, can I not be authenticated just once and be able to access all the services?
Any suggestion is appreciated. Thanks.
Typically in this scenario the user would authenticate once to the IdP when the first SP SSO's to it. There would be no authentication at the IdP when the second SP SSO's to it as there's already an authentication session at the IdP for the user.
However, there might be use cases where you want the user to be authenticated at the IdP even if they already have an authentication session. The SP can set the ForceAuthn flag in the SAML authn request sent to the IdP. This requests that the IdP authenticates the user regardless of whether or not they already have an authentication session.
ADFS also has a configuration option for relying parties (SPs) to always require authentication. Take a look at the AlwaysRequireAuthentication flag.
https://learn.microsoft.com/en-us/powershell/module/adfs/set-adfsrelyingpartytrust?view=windowsserver2022-ps
Our javaspring application (sp) allows SSO integration for the clients. We have planned to introduce SLO (Single Logout) as part of the security audit requirement.
I have a doubt, if our application request for SLO to idp then the particular customer's all other open app's get logged out ?
We don't want to make customer's other application get logged out due to our application.
Kindly advise. If the SAML SLO request will only impact the only the service provide which requests the logout or all the service provider which customer SSO logged in with?
Typically single-logout (SLO) will cascade from one SP to the IdP back to all related child sessions at the other SPs. Depending on what IdP you use, you may be able to control that / be more fine-grained but you have to be careful you're not opening yourself up to any attacks (on orphaned sessions).
As per SAML spec the IdP has to inform all other session participants.
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I'm in the midst of finding some means (preferably through Java code) that will enable me to get the SAML assertion from the IDP (i.e. ForgeRock's OpenAM) for a Service Provider (SP) via SSO Login.
The SP have already been configured to interact with the IDP (e.g. vCloud Director --> OpenAM and vice versa) through a Web Browser (i.e. the user will be automatically redirected to the OpenAM login page upon invoking the vCloud Director login page). However, this process is only applicable through browsers (where redirection is provided) but not outside the browser.
I can't seem to find any means to perform SSO Login (by using the SAML assertion from the IDP for authentication). So far I've come across a dozen of references including the AssertionIDRequestUtil.sendAssertionIDRequestURI function from the OpenAM SSO, still, I'm not sure where to retrieve the AssertionId and SAML EntityId parameters.
Are there other means of getting the SAML assertion? Or maybe other ways to perform SSO Login?
I think the easiest way to achieve this would be:
perform authentication via REST or ClientSDK
use a Java HTTP client to kick off an IdP initiated SAML authentication flow (/openam/idpssoinit?metaAlias=/idp&spEntityID=entityID). When you send this request you need to make sure that:
the session id is part of the request as an iPlanetDirectoryPro cookie,
session upgrade won't be performed (your authcontext settings at the IdP will have a lower or equal authLevel, than the level the session was created with in the first step)
Given:
PingFederate is a single-sign-on (SSO) solution, which allows users to be authenticated by 1-n applications using a single username and password.
High-Level Questions:
How does PingFederate's single-log-off (SLO) feature work?
And how does SLO work in general?
Given:
To begin the SLO process, we'd expect the user to request the SLO endpoint from the browser (i.e. https://[PingFederateInstance]/idp/startSLO.ping?PartnerSpId=[PartnerSpId]).
And we can assume that the PingFederate instance will issue a redirect after a succesful SLO invocation.
Specific Questions:
But what if you have multiple applications in multiple browser windows?
How could a federated identity provider tell multiple applications to terminate their user sessions?
Direct from the PingFederate Getting Started manual:
"The single logout (SLO) profile enables a user to log out of all participating sites in a federated session nearly simultaneously. The user may log out globally from any site, whether SP or IdP, as determined by respective Web applications. The associated IdP federation deployment handles all logout requests and responses for participating sites."
That said - PingFederate (acting as an IdP) knows which SPs you have federated with in a given session. When the user kicks off SLO (from the example you gave - at the IdP - it could also be initiated from an SP) the users browser (assuming a Redirect or POST binding) is sent to each SP with a SAML LogoutRequest.
If by "multiple browser windows" you mean independent browsers / browser sessions, then indeed PingFederate wouldn't know to logout of all the IdP's. You need to have some common session amongst them. So, if it's just multiple browser windows, but sharing the same session information (e.g.: cookies) this wil work fine.
For more information, you may want to consult section 4.4 of the SAML 2.0 Profiles spec: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Keep in mind PingFederate supports more than just SAML 2.0 - but not all federation protocols support SLO (e.g.: SAML 1.x). Also, many non-PingFederate SAML aware applications don't support SLO.