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.
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.
Let's say we have a service provider app called A hosted on tomcat, a user clicks a link to the SP A. SP A sees no token is provided so it redirects the user to the IdP for authentication (with a SAML Authn request provided by some means). The IdP then redirects the user to some common login page where credentials are provided, assuming that these credentials are correct the IdP creates a SAML response with a token and some assertions about the subject, and sends it back to SP A. SP A sees this and allows the user access into the application. Great!
I have a few questions though
How is the authorisation request/response sent, I understand there is a redirect binding and a POST binding where the SAMLResponse and request are encoded either as a query param, or sent as an XHTML form in case of a POST binding. But I'm not sure which is used where?
A service provider is the thing providing a service, so Office 365 or Sales force for example. Is each one a separate service provider? I ask as I watched a video where the guy said the service provider was the thing that hosted these services, so I'm not sure of the correct answer here?
How is the token stored on the client side? So for example I am now authenticated against SP A, the user then tries to use SP B from the same machine/browser window, how does SP B and the IdP know that the user has already authenticated and therefore doesn't need to re-authenticate. I.e. the SSO aspect of it.
Does SP B need to be hosted on the same tomcat instance for this to work?
I dedicated significant time to get SSO working for me. The most helpful document was this specification
The answers below are based on this experience:
Redirect or Post binding is used depending on a respective HTTP request header. The Post binding is recommended since it does not imply restrictions on data volume transferred.
A Service Provider in this context is anything that clients request. There may be many of them, participating in the same SSO scheme.
The service providers must be SSO-aware, which includes handling of the authentication response data. Usually you don't have to implement the protocol - there are ready-made frameworks that your SP can utilize.
Service Providers may reside on different servers.
From my own experience:
You choose your own SAMLBinding (redirect or post) depending on what your idp and sp supports. This binding type will be used both for the 1st step (SP -> Idp) and 2nd step (IdP -> SP). If you have some running environment, open your browser devtools and look at network tab to see what happens. It's just a way to send data from browser to SP/IdP.
Both Office 365 and Salesforce.com are cloud services, right? Let's take Office 365. it means that beyond "end-user" services (like Word, Excel) there is some technical SSO service which are common to the platform. It can be viewed as lower (or technical) service layers, I think that what you speaker meant.
The SAML token is stored by you SP application inside your browser, either hidden inside web page, cookie or web storage. It depends on how your SP is implemented.
SAML response can be validate by each SP based on shared private key, so it will decrypt the token using this key and be able to grant user without the help of IdP redirection.
Tomcat have some extension to support SAML. But SAML is designed to work without being on the same instance, as the opposite as basic JSESSIONID cookies.
So you have several instances, of course.
I have a scenario where I have four to five web based application, which needs to have a common centralized authentication system, in this case how feasible is the SAML based approach i.e each time user want to access any of these web application the user is redirected to SAML server which in return redirects to the IDP, or is their some better solution for such architecture as I am new to the this domain
What you describe is exactly what SAML is designed to solve.
The user is normally only redirected to the SAML Identity Provider (Idp) on the first access to an application (a service provider (SP)). When the user is successfully authenticated by the Idp, the SP sets a cookie in the user's browser to handle authentication of subsequent requests.
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).