I'm trying to set up a very simple SSO between two cooperating websites A and B. The scenario is as follows:
Suppose that I've visited website A and have been authenticated there with a normal username/password combo. I receive some type of token which identifies my session. I then navigate to website B and automatically want to be logged in. Ideally, I want my session preferences from A to be carried over to B.
I wonder:
Is there a standard for the token format?
Is there a standard for storing the token in the web session? (Cookie or otherwise)
Is there a standard for sending the token to website B? (Parameter names, URLs, Methods?)
Is there a standard for website A to contact website B in order to validate that the token is valid, assuming that B trusts A? It would be great if I could receive some metadata related to the user and session in this step as well (username, email, preferences set in session)
I've briefly looked into OAuth 1&2, OpenID, SAML and Mozilla Persona. They all seem to cover similar scenarios, but I can't quite make out if they would support this scenario and in to what extent. Any guidance is appreciated.
Thank you
Are these websites ASP.NET?
To do SSO, you need some sort of STS like ADFS v2.0.
If the sites are ASP.NET, then ADFS and WIF will provide the solution you need.
The two standards for Federation / SSO are SAML and WS-Federation.
SAML 1.0 token format is the one most widely used for the token.
There's a good description of all this here : A Guide to Claims-Based Identity and Access Control (2nd Edition)
Related
I have different web applications which are registered on IDM (vmware IDM https://github.com/vmware/idm/wiki/Integrating-Webapp-with-OAuth2#authentication-response)
As obvious, all applications are registered with there own client id and client secret. When a user tries to access webapp "A" (webappa.com), it redirects to my IDM login page and after authentication comes back with code that can be exchanged with access and refresh token.
Similar thing happens with webapp "B" etc. This works well. Now I am confused with following 2 use cases?
a. I want to use some API (webappa.com/api/v1/get_user_projects) from webapp "A" for some scripting purpose. So my question is how I can authenticate these APIs against the user? Can I get the tokens for the user from IDM provider by passing his credentials (using some APIs?). If answer to it is NO, then how usually it is handled?
b. Can webapp A and webaap B will have same access/ refresh token at a time against a user?
a.
When a user authenticates it is with certain permissions and for a certain period of time. OAuth is designed so that you can just forward tokens between microservices - but you cannot elevate the permissions or time for a user token. Depending on your use case you may want to consider a different token with different privileges for background tasks.
b.
It is possible but not advisable to follow the Google model via a cookie scoped to a web domain that hosts multiple apps, which is how Google do it (mail.google.com / drive.google.com). So there is a dependency on hosting and domains
The preferred option is for the user to authenticate at App A and then single sign on to App B. The different apps then get separate tokens with different permissions and can more easily evolve separately.
This also depends on how the app is implemented and your technology choices:
An 'old style' web app using a server side technology will expect to issue separate auth cookies per app
An SPA following an intelligent Back End for Front End design could support this model via SameSite cookies if it made sense for a set of related micro-UIs
In the latter case you would need to use a single OAuth client with multiple redirect URIs - eg for mail and drive - since the user could sign in to either of these first.
Apologies for the complicated answer - but it is a very architectural topic with the potential for hidden costs. From a stakeholder viewpoint it is very simple - make it work like Google. Hopefully this answer helps you in your conversations ...
I would like to provide some standarized SSO mechanism in my application (some different clients, growing number of services in the backend). I am wondering if OIDC/OAuth 2 is the right tool for it.
In all examples I have seen, end user is the Resource Owner and it grants permissions (or not) to some external apps by redidericting to a page asking for permissions.
My use case is different, I want to use OAuth inside my system (for apis, web pages etc.): resource owner is i.e. some service with database (plus administrator who have access to it), end user tries to get some resources from the system. User cannot grant anything, he can be granted. I think it's the most classic scenario, which can be named Single-Sign-On. Is there any standard flow for this in OAuth 2 (or preferably OpenId Connect)? Is it achievable? Or am I looking at a wrong tool?
OIDC/OAuth can be used for both consumer as well as enterprise scenario's. The consent steps of OAuth are useful in consumer oriented scenario's. When dealing with enterprise scenario's like yours, there's no point in asking consent since it is implicit, at least for the enterprise's apps. That is certainly covered by OAuth/OIDC: the Authorization Server is not required to ask for consent and can (typically) be configured to skip that step for particular Clients. So: using OpenID Connect without consent would be suitable.
For your usecase you can use combination of OpenID Connect and OAuth Client_Creds flow. For example suppose you have a HRMS application which needs to get the employee data to show to the employee from some DB.
Register HRMS with OPenID Provider
Register HRMS as Client to OAuth Server (OpenID Server and OAuth Server can be same)
When User comes to HRMS application:
a. Check for Id_token cookie, if not present then redirect to IDP
b. IDP authenticates and if successful redirects back to SP with ID token
c. If token is valid then SP sets the token as cookie in the browser using another redirect to itself but to the home page
Now All processing will be server side:
a. HRMS app hits the IDP to get the User Data
b. If successful then it hits the OAuth Server to get the access_token
c. if successful then it uses the access_token to talk to DB Service and
get the data
SP=Service Provider, IDP = Identity Provider
Actual flow can be a little different based on security considerations.
Hope this makes it helps.
I'ld like to implement SSO using SAML 2.0 in my web applications. I have seen spring-security-saml example [https://github.com/spring-projects/spring-security-saml.git]. There are a couple of things I wanted to know after I went through this sample:
Do I have to redirect all the user-registratons to the registration page of IDP as in this sample ? If not, how does the IDP know the credentials of the user?
Do the IDPs' like ssocircle (used in this sample) allow us to use customized attributes and change password kind of scenarios ?
What is the best IDP to use to implement saml sso in my application ?
Thanx in advance.
Q. Do I have to redirect all the user-registratons to the registration page of IDP as in this sample?
In SAML parlance, an application can be an identity provider (IDP) or a service provider (SP). An IDP authenticates users, which means that user identities and credentials are maintained by the IDP. An SP provides one or more service to the user.
From your question, it seems that you want to delegate the task of authenticating users of your application to an external party (the IDP). Therefore, your application will be the SP.
With that established, you will have to redirect all users to the IDP for authentication. The IDP's authentication page may have a link to the registration page, if required.
Q. How does the IDP know the credentials of the user?
The user must be registered with the IDP (after all, the purpose of the IDP is to authoritatively authenticate a user's identity, which it cannot do if the user is not registered with it). Users can be self-registered or registered by an administrator, such as, a Microsoft Active Directory Domain Administrator.
Q. What if I need to register the user in my system as well since I need to assign them roles specific to my system?
You can create your own implementation of org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler wherein you can check the authenticated user on successful single sign-on and register them with your application. Supply an instance of your implementation class as the redirect handler to the SAML entry point.
Do note that you will not have access to the user's password since that is stored by the IDP.
Q. Do the IDP's like SSOCircle allow us to use customized attributes?
SSOCircle is mostly a testing service for SSO (single sign-on). Although SAML supports custom attributes, SSOCircle only supports FirstName, LastName and EmailAddress (as of February 2016). Therefore no, you cannot use other custom attributes with SSOCircle.
Actual IDP's like Okta, OneLogin or Microsoft ADFS do support custom attributes. You must check their respective documentation for configuring and exchanging custom attributes between the IDP and the SP.
Q. Do the IDP's like SSOCircle support change-password kind of scenarios?
I am not sure about SSOCircle but an actual IDP will be a system that already has user identity management capabilities. Since password change is a common functionality for an identity management system, this should be supported with an actual IDP. However, you should consult the documentation for the actual IDP you use to make sure.
Q. What is the best IDP to use for my SAML application?
An IDP is not a product or a specification, making this question somewhat invalid. It is simply a type of actor in the SAML universe. If your users are part of a Microsoft Windows Active Directory forest, you can use Active Directory Federation Services (ADFS) to exchange SAML messages between Active Directory and your (SP) application(s).
If you want to support multiple Active Directory forests, or if you do not know in advance where your users will be, you can use delegation-based services like Okta or OneLogin, which allow your application to take incoming assertions from the delegation service.
Before you put me down for asking too basic a question without doing any homework, I'd like to say that I have been doing a lot of reading on these topics, but I'm still confused.
My needs seem simple enough. At my company, we have a bunch of Ruby on Rails applications. I want to build an SSO authentication service which all those applications should use.
Trying to do some research on how to go about doing this, I read about CAS, SAML and OAuth2. (I know that the "Auth" in OAuth stands for authorization, and not authentication, but I read enough articles saying how OAuth can be used for authentication just fine - this is one of them.)
Could someone tell me in simple terms what these 3 are? Are they alternatives (competing)? Is it even right to be comparing them?
And there are so many gems which all seem to be saying very similar stuff:
https://github.com/rubycas/rubycas-server and https://github.com/rubycas/rubycas-client
https://github.com/nbudin/devise_cas_authenticatable
https://github.com/onelogin/ruby-saml
CASino and https://github.com/rbCAS/casino-activerecord_authenticator
And I am sure there are hundreds of OAuth related gems.
I just want a separate Rails application which handles all the authentication for my other Rails apps.
Note: I do not want to allow users to use their Google / Facebook accounts to login. Our users already have accounts on our site. I want them to be able to login using that account once and be able to access all our apps without signing in again. Signing out in any app should sign them out of all apps.
UPDATE
I have come across these two OAuth solutions:
http://dev.mikamai.com/post/110722727899/oauth2-on-rails
http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/
They seem to be describing something very similar to what I want. But I haven't found any guide / blog post / tutorial showing how to do this with SAML / CAS.
Suggestions welcome.
UPDATE 2
More details about our use-case.
We do not have any existing SAML architecture in place. Primarily, it is going to be OUR users (registered directly on our website) who are going to be accessing all our applications. In the future, we may have third-party (partner) companies calling our APIs. We may also have users from these third-party (partner) companies (registered on their websites) accessing our apps.
CAS-Server:
A stand-alone central login page where the user enters their credentials (i.e. their username and password).
CAS supports the standardized SAML 1.1 protocol primarily to support
attribute release to clients and single sign-out.
(a table in a SQL database, ActiveDirectory/LDAP, Google accounts, etc.)
Full compatibility with the open, multi-platform CAS protocol (CAS clients are implemented for a wide range of platforms, including PHP, various Java frameworks, .NET, Zope, etc.)
Multi-language localization -- RubyCAS-Server automatically detects the user's preferred language and presents the appropriate interface.
SAML :
Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.
SAML authorization is a two step process and you are expected to implement support for both.
OAuth 2.0:
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.
Important Note :
SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don't get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.
On the other hand, with OAuth2 you can invalidate an access token on the Authorization Server, and disable it from further access to the Resource Server.
Both approaches have nice features and both will work for SSO. We have proved out both concepts in multiple languages and various kinds of applications. At the end of the day OAuth2 seems to be a better fit for our needs (since there isn't an existing SAML infrastructure in place to utilize).
OAuth2 provides a simpler and more standardized solution which covers
all of our current needs and avoids the use of workarounds for
interoperability with native applications.
When should I use which?
1.If your usecase involves SSO (when at least one actor or participant is an enterprise), then use SAML.
2.If your usecase involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.
3.If you need to provide access to a partner or customer application to your portal, then use SAML.
4.If your usecase requires a centralized identity source, then use SAML (Identity provider).
5.If your usecase involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate.
Reference 1,Reference 2,Reference 3
If you need to authenticate for LDAP or ActiveDirectory then a solution like one of the CAS gems you mentioned above is right for you (RubyCAS, CASino).
If you can afford it, one of the commercial vendors (like Okta) is your best option because they will stay on top of security patches and manage your authentication needs for you. In particular, if you have to support ActiveDirectory, they've already implemented it.
OAuth is most useful for third party authentication, though it can do SSO. So if you wanted to support Google / Facebook logins or be a third party authenticator then it's a great choice. Since you don't want to support Google / Facebook then OAuth is probably not what you want.
If you are only intending to use HTTP POST for your SSO needs then the ruby-saml gem could be the way to go. You would have to implement your own Identity provider and add a service provider component to all your websites (possibly in the form of a gem.) Part of what you would need is a rails api to act as your identity provider. This gem helps support writing API's in rails.
EDIT
You mention the possibility that future third party users might be logging on to your site. This changes your calculus away from rolling your own ruby-saml solution.
The best way to share your authentication API is to implement an OAuth layer. Doorkeeper is a popular solution and is fast becoming the standard for Rails authentication. It's community support, flexibility and ease of use make it the best way to go for a consumable authentication API.
Railscast for implementing doorkeeper
Anjan.
I've used CAS and OAuth in my work. Here are some of my opinions, and hope to help.
Basically
Both CAS and SAML aim to solve SSO situation. And CAS is a service or an authentication system, which can support SAML protocol.
OAuth aims to solve authorization and authentication.
And in practice,
Both CAS and SAML act as an gateway in front of a group of applications which belong to one organization. Just like your case.
OAuth is used to authorize and authenticate between different organizations.
Just my thoughts, and hope to hear more voices.
We have used CAS and SAML in our architecture (Mobile App, Online Portal, and MicroServices) and both are used for different purpose.
Our Online Portal is like online banking that runs in public domain and has to be secure. We don't want to store password and other secure token's in the DB of the online portal, therefore, we use CAS for authentication and authorization. During registration, when user chooses the password, we store the password in CAS and store corresponding token in the DB of Portal
When user login next time, User enters the user name and password in Portal. Portal fetches the token corresponding to user from DB and sends User_name, password, and token to CAS for validation.
But, in case user has already logged in into one application and we redirect user to our another application then we dont want to user to enter username and password again for second application. We use SAML to solve this. First application shares user details with SAML server and gets token in return. First application passes the token to second application. Second application sends token to SAML server to get user details and on success lands user to desired page. Our first application can be Mobile App and second can be Portal in the scenario of App2Web.
Since you have got lot of answers for this question, I would like to suggest you an identity product that can be cater these kind of all protocol in one hand with lot of authentication and user management features. You can just try WSO2 Identity Server version for this.
I'm suppose to build a web application and a mobile application (for iOS) that share the same database. Currently I'm thiking about having a RESTful API and have both applications (web and iOS) comunicate with the API to access data. My problem is the authentication method that I should use. I've been researching about OAuth2.0 but that's not quite the thing I want because I don't want the user to have to authorize the connection as it happens when you log in somewhere using facebook or google+. I just want to make the login with a username and password and then stay logged in. And this for both the apps (web and iOS).
I'm using Node.JS and MongoDB to build the API.
I'm trying to do things "the correct way" because this is suppose to be the final project for my masters.
Can you guys give me some lights in how I can achieve this?
Use OAuth 2.0 so you have an extensible standard and token-based authentication which enables users to revoke authentication tickets, e.g. if their phone was stolen.
OAuth 2.0 supports various grant types. Those that you from facebook and twitter logins can be summarized as '3-legged oauth', but there's also two grant types for 2-legged OAuth, especially the resource owner password credentials grant (section 4.3 at the end of the page) which will simply exchange username and password for an authentication token. There's no need to implement 3-legged oauth if you don't want to.
I'd suggest to use database-stored tokens over crypto-based self-validating tokens for most use cases. The possibility to revoke individual grants, or all grants of specific client applications is super helpful in practice. It also shortens tokens a lot and reduces the risk of a catastrophic security leak because of a flaw in the implementation. Make sure the token itself is crypto-strong random and use a simple crypto-wrapper around the actual token value to enable cheap identification of (badly) faked tokens.
Something like Passport (no, not the whisky, but the middleware) could be a good thing to test
It allows to choose among many different authentication methods in an easy and transparent way