I am using Kentor.AuthServices to implement Service Provider in a Web Forms application. I am seeing the SP redirect to idP and then POST the SAML to idP. However, it gets redirected back to idP again. I am guessing some configuration is not right, but not able to track it down.
Related
I am using keycloak as IDP, jersey rest services as backend and angular UI as frontend where my backend and frontend are separate application running on the same tomcat server.
Every example I found on the internet uses complete backend for SP initiated SAML SSO. I don't understand where does frontend contribute or how is frontend protected.
As when we talk about open id SSO protocol I found out that user agent calls frontend application which redirects user to IDP and gets the code and passes it on to backend. Backend does all the validation of the tokens.
So I had some questions
Is the flow in SAML same as open id if we have a frontend application?
Can frontend application produce SAML request and redirect user to the IDP?
After successful authentication IDP redirects to backend or to frontend?
How are services protected and where is the SAML assertion validated?
Is the flow in SAML same as open id if we have a frontend application?
more or less. User goes to front end application, is denied access as they don't have a valid session with the application.
Can frontend application produce SAML request and redirect user to the IDP?
yes. It would need to create a SAMLRequest containing an AuthNRequest and POST it to the SP.
After successful authentication IDP redirects to backend or to
frontend?
more or less. The IdP checks the SP Attribute Consumer Service (ACS) url in the metadata first. If it doesn't match, it refuses to send the SAMLResponse to the SP.
How are services protected and where is the SAML assertion validated?
It's up to the SP. If the user doesn't have a valid session at the application, they need to be redirected to the IdP and the application must validate the SAMLResponse and create a valid session for the user based on the attributes in that response.
Validation is done via X509 certificates contained in SAML metadata. It's complex stuff though.
I have created the circle of trust between the service provider and the openam IDP. The issue that we are facing is that I am always redirected at the select provider interface. What we want is that the user is been redirected directly for login and authenication to the IDP.
Here is the example used:
https://github.com/spring-projects/spring-security-saml/tree/2.0.0.M11/samples/boot/simple-service-provider/src/main/java/sample/config
Based on this I am redirected to the IDP select page, and I want to get redirected to the IDP login page for authentication.
If you only have one IdP in the list for bean id="metadata" this IdP will be used.
I'm getting started with Identity Server 4 (under ASP.NET Core) using the Implicit flow to secure an Angular 2 front end (to Web API services).
Using the oidc-client JS library, I can successfully redirect from the sample's default page to my login page, have the user authenticate, then redirect (via /connect/authorize) back the the Angular site's callback.
If a user browses directly to my authentication login page (rather than the Angular home page), I can then authenticate, but have nowhere to redirect to. If I redirect manually to the auth server's /connect/authorize page, the OIDC Client reports "No matching state found in storage". (Presumably, the OIDC Client is persisting something locally to verify the response against the original request?).
An obvious solution is for the Auth server to redirect any requests without a redirect specified to the Angular client, which could then redirect back to the Auth server as normal. That feels like a lot of round trips though.
Yes - because this is not how it works. The authentication flow starts at the client application - not the identity provider.
An OpenID Connect provider typically has more then one client - so it needs contextual information (aka a valid OIDC authorize request).
If you want that the journey starts at the provider you need to do something like you proposed - but once you have a 2nd client you need to be smarter about that (e.g. a selection screen etc).
Scenario:
Browser(User) requests resource from Service Provider (SP).
SP Redirects (with SAML Request) to Identity Provider (IdP).
Since it is first login, User gives the (IdP) his/her valid credentials.
IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
Application has a link to different application. The Second application needs to validate the user credentials with the same IdP.
User clicks on that link and browser opens the second application. Browser contains the same SAML response from SP.
In Step 5 how can I authenticate the user with SAML response and allow the user to be logged in automatically.
Do I need another SP?
I will not be able to use the SP from step 1 as it is external application.
Appreciate your help
If the second application is in a different administrative domain, it should be done through its own SAML SP starting another SAML request/response exchange with the IDP. If it is in the same domain you may be able to pass an intra-domain credential such as a cookie between the first application and the second (or rely on full SAML as well). You would never reuse the same SAML response because that is meant to be one-time use only.
I have a basic question regarding SAML2. Typical flow is that user requests a resource from SP that is protected. SP checks if the user has a security context (say cookie ?), if it does not find a security context, it constructs the AuthRequest and then redirects the browser to the IdP. Now IdP likewise first checks if the user has an existing security context. How does the IdP do this? Does the IdP also use a cookie for this purpose?
Yes. For SAML Web SSO Profile the session is almost always kept as a cookie in the browser at the IDP and SP. However, there are no rules on how to manage this. The IDP could choose to not keep an active session and prompt the user to login for each SSO transaction.
Ian
#Ian - Great Answer. However if the IDP does not maintain a session cookie [B/W Browser and Identity Provider (IDP)] than you miss out on a significant benefit of single sign on (SSO). The SSO User Experience (UX) feature that would be lost is described in the following scenario:
0) Assume IDP is registered with Google Apps and Salesforce.
1) Open Browser. NOTE: SAML is browser based. You need a browser for SAML to work.
2) Try to go to Google Apps; (you have no existing session cookie [B/W Browser and Google Apps]) who then Re-directs you to the IDP.
3) You sign on with your valid IDP credentials.
4) the IDP then stores a session cookie [B/W Browser and IDP] in your browser. (This is the step that #Ian mentioned can be skipped by the IDP)
5) The IDP then redirects you back to Google Apps (via HTTP POST) with SAML token embedded in the POST. You are now in Google Apps. (Now you have a session cookie [B/W Browser and Google Apps] stored on your browser)
5) Try to go to Salesforce.
6) Salesforce sees you have no active session cookie[B/W Browser and Salesforce], so they redirect you to the IDP.
* here is my point of added User Experience (UX) *
7) The IDP will look for a session cookie [B/W Browser and IDP], if the IDP is configured to not store maintain one you have to enter your Single Sign On (SSO) aka IDP Credentials AGAIN.
Discussion on Step7: Entering the SSO credentials for each separate service an extra-step times the number of services you are using. I think the main draw of the implementation is to enter credentials only once and get access to everything (the topic of security aside). However if the IDP does not store a session cookie [B/W Browser and IDP] you are still only using one set of credentials (instead of separate credentials for each service), so life is still easier.
#Ajava - You seem to be confused as to how cookies are used. I hope you can follow my steps above and get better idea of how cookies are used with SAML.
Here is also a good link i found that explains cookies: http://lifehacker.com/5461114/fact-and-fiction-the-truth-about-browser-cookies