We have a bunch of websites under re-built and few mobile apps under development. We are looking for a Identity Manager / Server that can be used for authentication and authorisation of the users logging into those portals and apps. I did some a brief research but could't find the answer to my questions below:
Does't MIM support OAuth2 / OpenId Connect based authentication protocol?
Can we create user profile and add users claims in it?
Does it have APIs that portals can call to add users into the user storage?
Does it provide API endpoints for change password and forgot password to add self serve password recovery feature on the portals?
I am a developer and have little knowledge about active directory and identity management area.
I was in the same boat you are in, and was trying to decide between MIM and Red Hat Keycloak. I ended up going with Keycloak, it is powerful yet easy to setup, configure, and manage, whereas MIM is a pain in the neck to setup.
It sounds like you are looking for a single signon or federation solution, if that's the case MIM won't be able to help you. MIM is designed to synchronise user accounts from an authoritative source and maintain them in other connected systems (typically HR to AD).
The equivalent product to Keycloak in the Microsoft space would be ADFS (Active Directory Federation Services) or Azure AD.
Related
I am currently working on a project that provides a services to enterprises companies. I want companies to be able to set up an account, and link their SSO to it allowing their employees to login. Each company account must have private data, so that other employees from other companies can't access their data. I must therefore be able to identify what account/company the user is from when they log in.
I have been looking into how to set something like this up, I know I should be using OAuth and SSO. But i have been struggling to find any documentation now how SSO integrates with OAuth. Can some one point me to a good guide/documentation on this?
At a high level this is federation, which should work like as follows - and nothing should need to change in your UIs and APIs:
Your UIs and APIs use tokens from your own Authorization Server
Your Authorization Server redirects to Company SSO Systems (Identity Providers)
These Identity Providers can use protocols such and Open Id Connect and SAML
My visual blog post may help you to understand the overall process. Account linking is the tricky bit, where you need to identify the user - most commonly by email - then perhaps match that to data in your own system.
My ASP.NET MVC web application is currently using on-premise SMTP server to send mails.
To understand, here is the classic scenario:
Users have to sign-in in the web app with a user/password (encrypted and stored in SQL DB)
Users fill in a form
When form is posted 2 mails are sent (one for the user and one for the team)
We have to migrate to an Azure VM (Virtual Machine) based solution. I am asked to use Microsoft Graph to send mails as a replacement of using SMTP server. I found a lot of documentation and tutorials on this subject. The classic solution asks the user to sign in using Open ID Connect and Azure AD is used for the authentication (MSAL). So a new authentication page is showed to the user where he should authorise the application to perform specific actions like sending mails (for example). See picture below.
In my situation, I prefer not force user to authenticate a second time. As explained in scenario above users already sign in with (basic) user/password not related to Azure AD.
So I thought I would use app's identity in place of user's identity. This way the user should not authenticate a second time. I found a quickstart on the Microsoft's website which seems to fit my needs.
Here is the link: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-netcore-daemon
Obviously I thought to integrate this concept in my ASP.NET web app and not in a console app but you get the idea.
So I would like to know if the solution of using app's identity in place of user's identity (authentication in Azure AD) to send mails in my ASP.NET web app is a good approach.
I think this is feasible.
In fact, Microsoft does not recommend users to log in to applications based on username/password, which requires a very high level of trust in the application and may bring certain risks.
In your question, you want to use the application to act as its own entity instead of performing operations on behalf of a specific user, so as to avoid repeated login authorization for users. I think this is a good method, but you have to pay attention, if you need to use the application's own identity request token to access MS graph api, then you must grant application permissions to the application, and then use the client credential flow as the authentication flow.
If you're using a VM you could enable managed identity and avoid dealing with credentials. Take a look to this article.
Background
We have created a web portal which our CUSTOMERS can use to host content for their users. Authentication is done through a login page where a CUSTOMER's user enters their email and address and password. Note: Our CUSTOMERS manages these emails. The portal works really well and serves our CUSTOMERS' needs really well. What they need now is the ability to allow our CUSTOMER to enable SSO from their website to our portal. They already know the email address of the user, as it's their customer or supplier. We are looking for the safest and easiest way to do this.
Our tech stack
It's all built on Azure and at the moment we are using ASP.NET MVC and SQL Server. Ideally, we would like to stick to this stack but we are open to any other suggestions. The website is SSL encrypted.
What I was thinking
Add Azure functions to enable a REST API. Give the CUSTOMER a unique API Key which they can use to request a unique "authenitcation_Key" from our API. The "authentication_key" should expire after 60 minutes and is unique for every CUSTOMER/user combination. When the already authenticated CUSTOMER's user clicks on the link/button to go from the CUSTOMER's website to our portal, the website gets a new "authenitcation_key" and adds it to the HTTP Header for us to consume and validate.
What are the major security concerns/risks to this approach? How can it easily be improved?
The one which you thinking to implement will take lots of time and security tests, why not to use industry proven solutions.
I would suggest you to use IdentityServer4, you easily configure this according to your need. I know you are using .NET full framework, but this will not stop you using IdentityServer4 which uses .NET Core.
Check here https://github.com/IdentityServer/IdentityServer4/
If your stack is on Azure, you may just set up an AZURE OpenID Connect server. Your CUSTOMER application can be registered as Openid Connect (or OAuth) client, each request can then send a JWT access_token to your portal, and your portal verify and accept JWT as authentication token.
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.
We are trying to build an ASP.NET MVC 5 web application where two types of users can log in. We have some clients who use Google apps and others use Office 365. Here we already know which client use what service.
The way users login to our website should be as follows:
User sees a page where user has to select their company name from a drop-down.
Depending on company name the user choose, s/he should be redirected to that particular SSO login page.
After authentication, the user shall return to our website, and be considered as authenticated.
Depending on the service they use, we are also planning to leverage their apis, like Calender, Notes, etc.
I searched a lot but found nothing/irrelevant in this regard. Please help.
If you want to implement this on your own, here are some tips from my experience:
Office365 (which is based on Windows Azure Active Directory): speaks a protocol called Ws-Federation with SAML tokens. To this moment, there are libraries for various platforms and languages.
Google Apps, is easier to Office365 since you have to use plain Google OAuth. One thing that might help you is that you can force the domain of Google Apps when doing the authentication by using the querystring parameter "hd" like "?hd=x.com". See this answer and the comments.
What you are trying to do it is not impossible but it requires some work and understanding all the protocols.
Another option is to use an authentication broker like Auth0. Your application sees auth0 as an OAuth provider and you can connect to your customers Google Apps and Office 365 from the dashboard or from an API which means that you can easily automate on-boarding customers. After you create the connection Auth0 will give you a link that you need to give to your customer so they can grant consent to your app to use their directory. From the client side perspective, you can achieve the combobox UI you describe by using auth0.js as follows:
var auth0 = new Auth0({
//settings provide by auth0
});
var combo = $('#company-combo');
//loads the company combobox directly from auth0
auth0.getConnections(function (err, connections) {
connections.forEach(function (c) {
$('<option>')
.attr('value', c.name)
.text(c.name)
.appendTo(combo);
})
});
//trigger login
$('.login').on('click', function (e) {
auth0.login({
connection: $("option:selected", combo).val()
})
});
Once the user logins, your application will get a profile. This profile has a property that indicates the connection/company.
Auth0 also provides an unified API to query/search users, in these two cases it uses the underlying directory but you get again the same profile representation.
Disclaimer: I work for Auth0.
You can use Windows Azure Active Directory ACS as a broker. From MSDN: Windows Azure Active Directory Access Control (also known as Access Control Service or ACS) is a cloud-based service that provides an easy way of authenticating and authorizing users to gain access to your web applications and services while allowing the features of authentication and authorization to be factored out of your code. Instead of implementing an authentication system with user accounts that are specific to your application, you can let ACS orchestrate the authentication and much of the authorization of your users. ACS integrates with standards-based identity providers, including enterprise directories such as Active Directory, and web identities such as Windows Live ID (Microsoft account), Google, Yahoo!, and Facebook.
This blog provides details steps on how to set up ACS.
This article explains how to use ACS in ASP.NET MVC.