Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In my understanding of SP-init and IDP-init SSO is as follow:
IDP-init SSO: A base64-encoded saml response is generated by IDP and send to SP, SP then verifies the response and finally the user is logged into the application if the response is valid.
SP-init SSO: A saml request is sent from SP to IDP, then IDP will authenticate the user then send back the saml response, the next part is same as IDP-init SSO.
How do we decide to choose whether the SSO is using SP-init or IDP-init ? SP-init seems to be more secure and reliable than IDP-init SSO because of the authentication part.
To me, the business requirements of the service provider's application tell you:
If all user interaction with the service provider's application will start at a "homepage", or default landing page, then IdP-initiated probably makes a lot of sense (less to break - no signed AuthnRequest needed).
If there are "deeplinks" that are provided to your users to things like reports via email (that is, a user can click on a link that should take them deep within the service provider's application), then SP-initiated is the only way forward.
In both instances, the user will be authenticated at the IdP based on the IdP's authentication rules - neither SP-init or IdP-init is "more secure" in that regard. The flows:
IdP-init:
User clicks link to start IdP-init SSO
IdP validates that User is authenticated - if not redirect for authentication
IdP converts authentication attributes (like username, email, etc.) into SAML assertion and redirects user to SP
SP converts SAML assertion to SP application token and redirects to application
SP-Init:
User clicks link to go to SP application
SP Application determines the user does not have a token and redirects to SP
SP redirects to IdP
IdP validates that User is authenticated - if not redirect for authentication
IdP converts authentication attributes (like username, email, etc.) into SAML assertion and redirects user to SP
SP converts SAML assertion to SP application token and redirects to application
The only difference, as you can see, is the first three steps.
You choose based on the desired or required navigation flow of a user (assuming browser POST binding based on your description).
If your requirements dictate the user start from secure (logged in) website A and navigate without password to site B, this is by definition IdP initiated.
If on the other hand the user is expected to be on an unauthenticated site yet log in with credentials from a partner site, this is where the SP initiated scenario comes into play. StackOverflow itself offers this style of sign in if you choose to log in with a Google account (though an alternative to SAML is used). The user starts somewhere on StackOverflow, clicks the login link, chooses their IdP (in SAML semantics) as Google, and are sent with an authn request to the IdP. After credential challenge of unspecified sort (eg your browser might already have an authenticated session at the IdP site, or the IdP might use two factor auth, etc) the user is returned to the SP site with a SAML response document.
SP-initialized is always to prefer. IDP-initilized will make work easier for the SP implementation but it comes with a buch of problems such as XSRF, interaoperability and deep linking.
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
I currently maintain an in-house SAML IDP written utilising LightSaml. This has served the company well for the last 2 years working with SP initiated SSO. I have recently been tasked with implementing IDP initiated SSO and I'm not able to work out how the user is automatically redirected to the desired protected page once they're authenticated.
In SP initiated SSO, the user starts at the page they want, therefore the SP knows where they want to end up after being authenticated. So in this case, the SP handles the final redirection.
In IDP initiated SSO, the SP doesn't actually know what protected page the user wants, so could someone explain what happens after the IDP sends the auth response to the SP?
Thanks in advance.
In IdP-initiated SSO, along with the SAML response, the IdP can send relay state. This relay state is the URL the SP should redirect to once SSO completes. If no relay state is sent, the SP will most likely redirect to some default page.
A typical scenario is that the IdP has a portal page with one or more links representing different pages at the SP. If the user clicks link #1, the IdP initiates SSO to the SP and sets the relay state to the page #1 URL. If the user clicks link #2, the IdP initiates SSO to the SP and sets the relay state to the page #2 URL.
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?
So I'm struggling a bit with the basics of the flow of SAML. Here's the scenario I find confusing.
I have a java web application. The user is logged in. I know they want to order cookies from a 3rd party because they've clicked on the "I want chocolate chip cookies" link. I also know that "Mrs. Pillsbury Cookies Co." is a "Service Provider" because she sent me her meta-data and I've registered her with my Gluu Server (IdP). I've also sent her my IdP meta-data so we've done the whole hand-shaking thing.
My question is...how do I now send the SAMLResponse to Mrs. Pillsbury? She's given me a SOAP endpoint that is waiting for a SAMLResponse. How do I tell my Java application to get some XML from my gluu server as a SAMLReponse that I can then pass to the Pillsbury SOAP endpoint? That's the part where I'm stuck...I don't know how to get a response to forward. I can see in the metadata that there are lots of SSO endpoints
<SingleSignOnService Binding="urn:mace:shibboleth:2.0:profiles:AuthnRequest" Location="https://idp.myjavaapp.com/idp/profile/SAML2/Unsolicited/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.myjavaapp.com/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.myjavaapp.com/idp/profile/SAML2/POST-SimpleSign/SSO
Am I supposed to hit one of those SSO endpoints and it'll generate a response that I can then forward on to Pillsbury? Can one of you SAML experts out there get me straigtened out? Thanks in advance.
There are a few ways SAML Requests/Responses can be generated.
IdP initiated:
This is a SAML Response generated w/o a SAML request. This requires the user to login/be logged into the idP and the idP will generate a SAML Response based off the SP setup in the idp.
SP initiated:
This is usually an HTTP Redirect but can be a POST as well. This is a SAML Request Redirect/POST that gets sent to the idP based of some link or button on the SP's website.
As I understand it you have the following relationship:
Your App
\
3rd Party ordering
/
IdP Server
Your app needs to make a request to the 3rd party, but also need it to authenticate against the IdP. Yes?
Normally the process works such that the 3rd party requests the token itself. Your app shouldn't have the token intended for the 3rd party -- it should only have the token for its own app.
Usually you send whatever your app-specific request is to the 3rd party first. When they receive that bit of information they hold onto it and then make a SP-Initiated authentication request to your IdP. They will attach a bit of information as part of the auth request called relay state. This bit of information is used to reconstitute the session after the IdP responds.
Once the IdP receives the request it does whatever it needs to do to authenticate the user, and sends the token back to the 3rd party. As part of that response they also send the relay state. The 3rd party then verifies the token and sets the session as necessary, then reads the relay state and sets whatever internal state is necessary to continue the order.
You're on the right track. As the previous answers have explained, it can be done one of two ways: the SP site (Pillsbury) sends you an authentication request, or you can direct your IDP/Gluu server to send an SAML message to the SP without them prompting: "unsolicited".
In the case of the first "SP-Initiated", you just create a link to the SP site for the user's browser to follow. The user's browser hits the SP site, the SP site realizes that it needs to authenticate the user: so it creates a SAML Authentication Request to your IDP endpoint, directing the user's browser there. Then your IDP server will respond according to the metadata/relationship that you've set up with the SP site. Just as one of the other answers explained, this Authentication Request can include a RelayState parameter which will be sent back to the SP to tell them where to send the user after the SAML message had been consumed & validated. I haven't used Gluu but I believe the SP would use the second endpoint you showed in your question to do this.
In the case of the second "IDP-initiated", you need to direct the user's browser to one of the Gluu server endpoints to generate a SAML assertion, which will be POST'd back to the SP site without the SP site's prompting. This one is less used because every time the user is directed to the SP site from your site, they will be forced through the AuthN process among other reasons. I believe this is the first listed endpoint that you showed in your question.
Here's a really good explanation of IDP-initiated from Shibboleth, that should help clear this up for you: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO
Best of luck!
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.