Our company has a Rails application hosted on Heroku. It currently uses Devise for user authentication.
One of our clients wants to know if their users could access our application using their ADFS implementation.
Would we be able to use Heroku Integrated security with Identity
Federation?
Would we need a 3rd party like Auth0?
Can Devise use ADFS?
Should we use OmniAuth SAML?
Not sure where to start.
I work at Stormpath, we provide an addon service in the Heroku webstore: https://elements.heroku.com/addons/stormpath
Stormpath lets you store users and authenticate them against the typical username/password stuff, AD / LDAP, SAML providers, social login providers, etc.
It pretty much supports all of the stuff you'd want to do around authentication / authorization.
Now: the way the AD stuff works is pretty cool. You have to have your client install an AD agent on their network which will basically create a reverse tunnel between their network and Stormpath.
That agent will then copy over user data into Stormpath (usrenames, email, groups, etc.), but NOT password hashes.
When a user authenticates against your site, and you make the request to Stormpath -- we'll basically talk to your AD server over that tunnel, authenticate the user against your AD server, then return a 'standardized' Stormpath Account model to make it easier to work with.
All in all: it's a really nice solution that works really well in production.
Related
How do I best configure Keycloak so that a user needs to have an account for a client to be able to login into that client?
I have to replace a proprietory SSO-Impl. It deals with users, roles and clients much like Keycloak. However, it also knows about accounts. A user is only allowed to login to a client if he has an account for that client.
In Keycloak, if a user simply exists in a realm he may login to a client of that realm. Nothing else is needed. So no "account" is needed. In the old application, he needs an account as well.
What functionality in Keycloak is best suited to overcome this difference?
I have one idea:
Create a client-role in each client namend "HasAccount" and assign it to users. Then, restrict access if that role is missing.
This is discussed here: "Restrict client access in a single realm with keycloak"
It has at least two drawbacks:
It mixes authentication and authorization in the legacy app. I can understand that. But creating a role was already a workaround. That is why I described my initial problem here.
I have clients in 3+ languages/technologies. Adding functionality there seems like more work than in Keycloak.
Last remark:
Before you ask "This is not single sign on" anymore. It is only for administrative purposes. The admin can allow users to login into a client or not by creating an account or not. The user does not have to login a second time. If he is logged in in App A and has an account for App B, accessing App B works without logging in there.
A user is only allowed to login to a client if he has an account for that client. is really not a task for Identity Provider (IdP). It provides only identity and not authorization.
Of course you can ignore that and implement authorization as well. See: User attribute based web service access control by Keycloak
From the design perspective I would add auth reverse proxy in front of legacy app (but it isn't a best solution for SPA apps). Auth proxy will provide authentication via OIDC protocol and also authorization. Legacy apps may keep own OIDC authentication - it will be seamless auth from the user perspective, because SSO will be used.
Account entity - you can use group entity in the Keycloak instead of original account.
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.
Is there a good way to implement 2-Factor authentication on an MVC web application that is using Windows Authentication?
I see examples that show how to implement 2-Factor on a Forms-based MVC app, but couldn't find one for a Windows-based MVC app.
Any help would be appreciated!
2-factor doesn't make sense in the context of Windows Auth. The application is authorized by the user's domain account. The security aspect lies on the domain-end, not the application-end.
However, if you're dead set on doing this, you effectively can't use Windows Auth. That sounds a little contradictory, I know. How you would have to handle this is use application-based authentication, such as Identity, so the web application itself would hold the user accounts. Then, you can authenticate via connecting to LDAP directly. You'll have to set all this up yourself, in other words; no easy set it and forget like you get with Windows Auth. With something like Identity, you can implement 2-factor auth, so you're golden there. However, instead of validating the password via your application's database and users, you authenticate via LDAP.
This is actually pretty common among enterprise-class applications utilizing AD. Typically, they'll have a script that you can run, as a consumer of the app, to periodically update the application's user database from AD, so all the same users with the same details exist in both places, except for the password, which remains solely with AD. This way, the application can associate its own data with its copy of the user, but authentication and authorization still happens at the AD level.
I'm creating a mobile application that uses a server to store data into. I am also creating web application that will function as a restful database service for my mobile application.
I plan to use Keycloak for my user management and authentication (Oauth2) of my mobile. I understand that Keycloak has an endpoint for user registration but it requires the mobile app to redirect to the keycloak server url. If possible I would like to avoid this and do all the process within the mobile application. Also, I'm unaware of the other endpoints such as password reset and forgot password. Would anyone know?
You need to use the admin API to include it in your mobile app. Personally I think this is a bad idea to do it directly on the client, because you need to store the credentials of an admin on the mobile as well. Maybe it is an option for you to have backend application, which handles your password forgot use cases and include it in your mobile app.
This seems to be related to this question: Is there an API call for changing user password on keycloak?.
Admin REST Api: http://keycloak.github.io/docs/rest-api/index.html
Endpoints for clients: /auth/realms/{client-id}/.well-known/openid-configuration
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.