Our business use case is that we have four to five services deployed as java spring web applications. These services have user/customers derived from either registration process or some existing running applications exposed as rest services. We intend to make a single portal which provides users to be able to use a single account / credential to log into many services directly.
With internal approach we assume having individual customer table for each services. And a common Login table for all services whose id is tagged/mapped as foreign key in individual customer table of each services.
Also some services can be accessed without registration , in that case we fetch the data via customers account id from some third rest service and store it in individual services/application customer table and in common Login Table if not already present.
For services which require registration we store the customer credentials in login table if not present; and also in service/applications customer table with a common login table mapping.
But we need a secure portal with session tracking , session timeout just like Single Sign On
With some research we have narrowed the approach to implement the above scenario with either SSO or Oauth2 which her is applicable.
Refer the link (https://stormpath.com/blog/oauth-is-not-sso ) for more insight.
Can someone suggest which approach SSO or Oauth2 is applicable for our business usecase ?
if SSO , which is the best opensource simple SSO for java Spring applications?
if OAuth2 , what will act as Client application, Authorization Server , Resource Owner and Resource Server? As we have services(Java applications) as client application hosted in Common Application/Portal? will the common login table act as resource owner ?
You will likely want SpingSAML. If the applications are hosted on separate paths, like example.org/app1 and example.org/app2 then you could use a Shibboleth Service Provider as the SAML SP for the applications.
You'll still need an Identity Provider of some sort, which SpingSAML can't do, but there are innumerable IdP implementations out there: i.e. Shibboleth Identity Provider, ADFS, or a commercial IdP like Okta, OneLogin, Ping, etc.
Related
I'm new to OAuth2 and trying to figure out what is the best practice for the following scenario:
I'm implementing 'ToDo' web service (CRUD for 'tasks')
I'm using OAuth2 and Google as auth provider to get user details (email, name)
Now I need to implement project-specific roles for users ('admin', 'user')
Speaking in terms of OAuth2 - Google doesn't 'own' my service, so it cannot help me with storing/providing 'ToDo'-specific roles, is it correct?
What is the common/best approach to implement it, do I need to create my own authorization service where I'll need to store relations like userinfo -> project-specific role?
Well, it depends what, exactly, you're looking to do.
If you have users, and those users have specific roles that you have assigned to them already, then you're just using Google's OAuth service as an identity service. You don't need to implement your own authorization service, but you will need to keep track (typically in your own database) a relationship between the userid and the roles for that users.
If the goal is to create a service where the user can delegate specific permissions they have to a third-party service, then you will certainly need to implement your own OAuth server. This will allow the user to limit the scopes that are necessary for the third-party service to do its job.
It is easy for you to setup your own authorization and resource server rather than depending on google services. In your own authentication server you have more control over your roles and users you specify.
You can setup and authentications server using spring boot app and using dependencies like Spring-starter-security, spring-security-oauth2 and etc.
Yes, you'll have to use your own Authorization Server that can then issue tokens that have realm-specific roles associated with them.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
I want to allow users of a SaaS based, asp.net MVC, Multi-tenant DB to login using their social media credentials (FB, TW, G+, etc).
In addition to the social media account validation, how can we determine which tenant or users within a tenant in the DB to validate against? I presume some flavor of Asp.Net Identity should be used to bridge the gap??
I have implemented a custom OAuth server that inturn handles the pluggability of the various social media login modes via OWIN middlewares.
However, when you wanted to have a simplified approach, you can choose to go with Windows Azure Access Control service which can enable you to identify the tenant via their URI.
In that case, you can infer the tenant name or tenant unique value from the URI [like a subdomain part] of the URI.Host.
You may refer here / here / here.
In case you wanted to build your own model, you will have to capture the tenant information via either a unique URI from where the tenant comes from or from getting a tenant unique value from the UI or as a query string from a URI [Rare & least secure case].
The points worth pondering upon will be
Time
Cost [Azure does not come for free]
Customization aspects
Please share your thoughts on the points above.
I'm going to be undertaking a large project for a client of mine. I need to write an IDP (identity provider) that will handle single-sign-on to multiple apps by a number of different authentication methods (such as SAML, OAuth, Form-based auth, HTTP Basic auth). I'd also need the ability to add in additional types of authentication as the app grows.
The basic idea would be that we'd have three different components to the app. One would be the IDP. Another would be a data-store that contains user accounts, the apps they want to use, etc. The third would be a GUI front-end that allows users to sign into apps.
It seems that there are some existing gems that handle authentication, like https://github.com/onelogin/ruby-saml and https://github.com/intridea/omniauth. My question is, am I overcomplicating this project -- would I just be able to use existing gems like these to act as the IDP, or is this a project where I'd need to read specs and implement them myself in Ruby?
Using something like SAML toolkit for Ruby on Rails adapted to work with ADFS server, you can integrate with ADFS. Now you can leverage ADFS features:
Interface with Facebook etc. via Azure ACS
Interface with Azure Active Directory and hence SSO to SaaS applications
Azure Active Directory Multi Factor Authentication
BYOD via the Web Applications Proxy
OAuth on ADFS 3.0
and so on. The list is expanding all the time.
Once you hook into these standards. you just inherit all the new features as they are released.
I am putting a plan together for a series of sites that will share user account information among them. The idea is that once a user logs in using their OpenID, they can access any of the sites and it will know who they are.
What are the common patterns/best practices that i could employ to achieve this?
If all the sites share a common hostname in their URL then you can set an auth cookie (FormsAuthentication.SetAuthCookie) specifying the path of the cookie to be "/" so that all sites can see the user is logged in.
If the sites are not sharing a common host name, I think the only way to get a truly "once signed in, signed in everywhere [within your ring of web sites]" would be for all authentication to happen at just one site (perhaps one dedicated to authenticating the user) and for the other sites to redirect the user to that site for authentication and then that site would redirect back. In essence, that auth site becomes an identity provider, and almost exactly fills the role of an OpenID Provider (in fact DotNetOpenAuth could be used here for this exact purpose). Since it sounds like your goal is to let the user log in with their OpenID, your OpenID Provider on that one auth site could itself use OpenID to authenticate the user. Your own pure-delegation OpenID Provider could be written such that it always responds immediately to checkid_immediate requests as long as the Realm in the auth request is one of your trusted ring of sites. Thus you could effect single-sign-on across all your sites.
Please consider the following Patterns & Practices on Web Service Security from Microsoft:
Brokered Authentication - http://msdn.microsoft.com/en-us/library/aa480560.aspx
The main topic is - Web Service Security
Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
http://msdn.microsoft.com/en-us/library/aa480545.aspx
Ultimately theres lots of ways you could do it. I achieved a simple single sign on by building a url with a token from one website pointing to another domain. The encoded & encrypted token contained details to submit back to the previous domain. Upon receiving an incoming request on the second domain, an underlying web service checks that the incoming request's token is valid with the previous domain using a shared private secret, known to both domains.