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
Related
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?
What I have right now?
I have a working SP-initiated flow where users can authenticate against their IDP. If they return after some time and click on SP-initiated authentication link, IDP lets them bypass entering credentials.
Question
Why does IDP decide to allow the user to jump over entering credentials? I have discovered if I delete my cookies this does not happen. Is this then IDP set cookie and IDP controlled session? Can I control this via SAML Request?
Can I enforce IDP to always ask for credentials by setting a FOO SAML Request flag? Is this even possible?
Most of the times the point of introducing SAML-based federated SSO is that users don't have to enter their credentials over and over again. So not having to type their credentials is a feature of the IDP.
But the behavior is completely up to the IDP who controls how and when the user authenticates. The SP can ask for forced authentication but it is still the IDP that decides if that request is honored (by following the spec).
An IDP may skip asking for credentials explicitly if the user has logged in explicitly within a short timeframe before the current authentication request. That's still relatively secure and convenient for the user.
you can force IdP to always prompt user for re-authentication by passing ForceAuthn=true attribute in authentication request.
I'm knew to SAML and i'm trying to understand how a clients details are stored for SSO.
If select a link in a browser to a service provider and I haven't been set up on the IDp after I have my account created at the IDp and authenticated to the SP what is stored? is it my ipddress? if I tried to connect to the same SP from a different machine would I need to be registered on the IDp again.
Or is it done another way?
Thank You
An IdP creates a SAML assertion about an authenticated subject.
Based upon the NameID format being used an opaque handle could be transmitted ("transient NameID format") or an email address ("email NameID format") or even some other id can be transmitted from the IdP to the SP. Furhtermore attribute statements could be used to transmit additional information about the subject.
Authentication happens on the IdP, however it's not defined in the SAMLv2 spec how this has to take place.
If authentication happened a "session" is established at the IdP. Most IdP implemenatations use a cookie to track the "session". So when you return to the IdP again there is no need for re-authentication unless an SP mandates this. ("ForceAuth" in the SAML AuthnRequest).
This is only a quick overview, reading the SAMLv2 tech overview (https://wiki.oasis-open.org/security/Saml2TechOverview) certainly gives you more insights.
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 creating a service provider which talks to third party IDP for authentication. But I have a concern that I have a set of dedicated machines(Desktop,tab) which are highly trusted, so is their a way in SAML that when a request is sent from such machines user is directly authenticated without the need to type username and password.
you want that user that tries to access a resource from his desktop (which is trusted) will be automatically authenticated? if this is the case, it seems that you need to identify the user using the active directory or something.
if this is the case, search a bit about Kerberos, or ADFS - it might serve your needs.