We have 4 applications. And we want to implement SSO across these apps. I have several doubts regarding this. We were suggested to use opensaml.
Query 1:
The username and password entered by the user is sent by client(Ex.Front-end) to the middleware and then the middleware send this information to the SSO server,Then in this case
Is the user a principal??
Is the middleware a Service Provider?
Is the SSO server a Identity Provider?
Query 2:
Now when an user logins in one of the application then we should connect to Identity Provider to initiate the SSO, what parameters(Mandatory) should be sent the by us to SSO server??
Query 3:
When After getting response from SSO server, Should middleware keep the token for future reference?
Query 4:
Now if the another user hits another application then it should be identified that there is sso working on. How to identify that?
Should the middleware hit the SSO server for that?
Kindly resolve above queries.
1) Yes, the 'middleware' you describe is the Service Provider and the 'SSO server' is the Identity Provider.
2) When the user attempts a protected resource on the Service Provider, it will redirect the browser to the Identity Provider. If the browser does not have an active session with the Identity Provider the user will be prompted for login details.
Following which the browser will be redirected back to the Service Provider along with the SAML response authenticating the user. After verifying the SAML response the Service Provider will redirect to the protected resource.
Once the user is authenticated the Service Provider can keep it's own session to save redirecting to the Identity Provider for every request.
3) The Service Provider (middleware) would not normally keep the SAML response from the Identity Provider, instead it can set up it's own session. For example in .Net this can be down via Forms Authentication.
4) When the user tries to access another Service Provider, the browser will be redirected to the Identity Provider. As the user already has an active session, the Identity Provider will redirect back to the Service Provider with the SAML repsonse. The service provider will then redirect to the protected resource and optionally create it's own session.
This happens seamlessly to the user, and they are effectively logged straight into the second Service Provider.
Also which platform are you using for development? If you are using .NET or Java then I can recommend the open source library OIOSAML. It includes working examples of both Service and Identity Providers so you can see how things work.
What IDP are you thinking of using?
In the SAML world, all the URL's, certificates etc. are exchanged via metadata.
So in the IDP you would import sp.xml and in the SP you would import idp.xml.
For Java, you would need some kind of SAML stack on your SP side.
Refer: SAML stack and Java equivalent to WIF.
Related
In one of my developments (using kerberos authentication to loginalong with HtmlUnit) its working fine in all cases , facing an issue after hitting SSO authenticated links where the SAML2 used.
I have searched all the way there is no proper explanation to get more info on SAML2 authentication for SSO secured pages.
I`m completely new for SSO authentication and SAML2 authentication,is there any separate API for this? help me to know on more on this.
Could you please help or suggest what is the best process to pass the user/password to get the authentication.
Thanks
Authentication itself is not part of SAMLv2 specification. SAMLv2 defines the exchange of information about authenticated subjects. Authentication happens at the SAMLv2 IdP. How this happens in detail is up to the IdP.
It could be that the following is possible in your case ...
Use HTTP POST to send credentials to the Login URL of the IdP. Capture the session cookie returned by the IdP. Send HTTP request to the endpoint of the IdP which allows so called IdP-initiated SSO and specify 'HTTP Redirect Binding' and the Meta Alias of the SP (this is the SSO-enabled app from SAML point of view). The IdP would return a 302 , follow the redirect, the SP should consume the SAML assertion included as a query parameter and you should be able to access the SSO-enabled app.
You may read SAMLv2 tech overview (http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html) to get some idea.
I need to use WSO2 Identity server with SAML for SSO for my internal application. I came across this beautiful
SAML2.0 SSO with the WSO2 Identity Server article
But i have two questions on this article which i am not sure how works
1) In 5th step it is said "Now the user is being redirected to IDP again. Now the IDP realize this user is already authenticated hence it would issue
a SAML Assertion without prompting any authentication challenge."
How will the IDP realize that user is already authenticated ?
As per my understanding it must be done based on session. Does it mean when authentication request goes from service provider 1 to Identity server (SP1 redirects the request to IS thru browser ), IS will first authenticate the credentials and if successful keep the user object under session.
Now when second authentication request goes to IS thru SP2, same session ID is sent (provided request is sent from another of same browser), IS fins already a user object associated with this session, so trust him. Is this understanding correct?
2)In step 2 it is said that " Now the SP1 can validate the SAML Assertion issued by IDP and let the user log-in. "
what is the specific field/value (under SAML response sent by IP) , SP1 will verify?
3) Where user credentials are stored. Is it on IS side or Service provider side?
Just explain how it works with WSO2IS 5.0.0
When user is authenticated to IDP by providing credentials. WSO2IS creates an authenticated session for user and cookie with is associated with the authenticated session set in to the user's browser. Cookie name would be commonAuthId. you can also find it in your browser once you are authenticated with WSO2IS using SSO. Then user is trying to access another SP using same browser, cookie would be sent in to the WSO2IS and it identifies that there is an authenticated session related to the cookie.
Usually, SP validates the SAML2 Response and Assertion. There are several validations that you can do. But most common would be
Signature of the SAML2 Response and SAML2 Assertion
Validity period SAML2 Response and SAML2 Assertion.
Audience restriction validation in SAML2 Assertion
Destination url and Recipient value
Normally Username would be extracted from the Subject identifier value. Also there may be attributes in the attribute statement, which SP can retrieve and do some validation over them as well.
End users are authenticated to the IDP. So credentials must be in IDP not with the SP. It is one of idea of SSO. Maintains the credentials in one place. WSO2IS is default shipped with LDAP based user store. Therefore end user credentials are stored in the LDAP server. However WSO2IS can be deployed with any existing user stores that you like
We are implementing Single Sign On [SSO] across multiple applications, which are hosted on different domains and different servers.
Now as shown in the picture, We are introducing a Authenticate Server which actually interacts with LDAP and authenticate the users. The applications, which will be used/talk to Authenticate Server are hosted across different Servers and domains.
for SSO, I can't use session variables, as there are different servers and different applications, different domains, a domain level cookie/session variable is not helpful.
I am looking a better solution which can be used for SSO across them. Any demonstrated implementation is existing? If so, please post it or point me in the right direction for this.
You can achieve this by having all your log-ins happen on the auth server. The other applications can communicate to the auth server through a back channel. The general principle is like this:
User accesses application 1.
Application 1 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 1 then redirects the user to the log in page on the auth server with the token as a parameter on the request.
User logs in to auth server. Auth server sets a cookie, flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 1.
Application 1 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
Application 1 now knows that the user is authorised and has some basic user details.
Now this is where the SSO bit comes in:
User accesses application 2.
Application 2 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 2 then redirects the user to the login page on the auth server with the token as a parameter on the request.
Auth server sees that there is a valid log in cookie, so it can tell that the user is already authenticated, and knows who they are. Auth server flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 2.
Application 2 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
Application 2 now knows that the user is authorised and has some basic user details.
There are some existing implementations of this method, for example CAS (Central Authentication Service). Note that CAS is supported out of the box in Spring Security. I would advise you look at using an existing implementation, as writing your own will be hard. I have simplified things in my answer and there is a lot of potential for introducing security holes if you're new to this.
I will recommend you check out OAuth. It is a good Authenticaiton and Authorization protocol used by several large organizations including facebook, google, windows live and others. It may have an initial learning curve, but it is a production grade solution.
It also has libraries for Java, Ruby, PHP and a range of other programming languages.
For example, the following server side implementations are available for Java.
Apache Amber (draft 22)
Spring Security for OAuth
Apis Authorization Server (v2-31)
Restlet Framework (draft 30)
Apache CXF
Following client side Java libraries are also available:
Apache Amber (draft 22)
Spring Social
Spring Security for OAuth
Restlet Framework (draft 30)
Please refer here for more details:
http://oauth.net/2/
http://oauth.net/documentation/
The bigger question is how you are implementing single sign on. Many open source and even proprietary (IBM Tivoli) offerings worth their salt offer cross domain single sign on capability. This would be the easiest and best way to implement cross domain sso. You can configure the LDAP server you use in the sso server you choose.
Taking for instance open sso, here is an article to configure cross domain single sign on
http://docs.oracle.com/cd/E19681-01/820-5816/aeabl/index.html
To configure LDAP in open sso,
http://docs.oracle.com/cd/E19316-01/820-3886/ghtmw/index.html
Reference on the issue is presented in a neat diagram here
http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html
Depending on which offering you use, you can configure cross domain single sign on.
With this, your diagram will look like this, with the auth server being your utility to interact with sso server of your choice.
Having an auth server that communicates with sso is a sound architecture principle. I would suggest making calls to authenticate as REst end points which could be called via http from different applications.
You cannot use Rest Service .
You could use what i call a Refferer Url Authentication
Say you have a Authentication application running on www.AAAA.com
In the applications , where you want to authenticate , you could have a filter which looks for a authenticated cookie in its domain else redirect to www.AAAA.com for authentication
On Successfull authentication , you could pass the user profile information as encrypted GET / POST data back to the application
Since I have built a Java application, I have been looking for an SSO solution for it. I found a free Java SAML Connector using which you can achieve SSO in java based applications built using any java framework.
Here's the link to it - https://plugins.miniorange.com/java-single-sign-on-sso-connector
I'm developing a html5+jquery+phonegap application. Server side is written in java and Spring MVC.And I hope to implement an authentication model as follows.
client signs up using his email which would be used as his userID.
A token is sent to his email.
He is given a screen to enter the token.
That token is stored in the local storage of the client.
everytime the client calls a webservice, his userID and token is sent by the app over https.
Server authenticates him and responds.
What are the options available to implment this kind of security from the server side? can Spring-security be used in this way? I tried to find any implmentation with Spring-security, but couldn't find any implmentation other than basic authentication.
You can use PreAuthenticationProcessingFilter to achieve this requirement, have a look similar case and spring security doc
I am developing a web service using Spring framework for Java and deploy on JBoss AS. This web service needs authentication and authorization and security solution so that some method user A can execute and some other user B can execute. At client side, there will be an application calling to the web service and people may log in using either user account A or B.
I have been digging out the Internet, searching for web service authentication, researching on WS-Security but all that I can see is using WS-Security. WS-Security generally supplies 4 kinds of authentication:
UsernameToken
X.509 Token
SAML Token
Kerberos Token
But all those things are usually pre-configured and I find no example that suggest I should provide login/logout methods in the web service (by using stateful web service). Note that in case we use login methods then there are security risks even if the underlying is SSL transport.
So my question is:
What should I do to satisfy my requirements?
If using UsernameToken or Kerberos Token ... and we provide some privileges per user, i.e authorization, then for each incoming request, we must get the user information and get all its privileges. This process seems take time and decrease performance of the system. Do you agree? So I guess this is not recommended?
I would thank you so much for any response and will vote for any reasonable answer.
Your scenario mirrors that of EBay Trading API's.
Basically, it works as follow.
Provide a intial WS call (Ebay case: FetchToken) which confirms user's identity and return back authorization key (unique key for each logged in user). Store the authorization key along with user profile information in a cache/distributed cache .
Any subsequent call required client to pass the authorization key along with the data for the call. You will use the authorization key to get user profile information.
Provide the log out WS call. This invalidates the authorization key.
All the WS invocations should happen over SSL for security.
If your service is point to point, ssl is enough. Mutual ssl (Mutual_authentication) is widely used for client authN and authZ.
If you concert about performance of system, looking at SAML. SAML is a signed XML document that contains authN and authZ for client, that means you do not need to loop up on the server for client authN and authZ.