Is there a Java provider implementation of the OAuth's Resource Owner Password flow or a library to include in my project?
I have read that Spring Security provides those libraries with a server or provider implementation, can I only include those Spring libraries to my standard Java EE project without using the full Spring stack?
Could it be possible or reasonable to implement the OAuth provider and client for that flow following the RFC?
The UAA project uses Spring Security's OAuth provider to implement a full OAuth2 authorization server (including resource owner grant). Why not use that?
You can't "only include those Spring libraries to my standard Java EE project" without using Spring. It's not really clear from your question how you would expect that to work. Where would the authorization server be implemented, for example?
It's certainly possible to implement the OAuth2 provider yourself, especially if you are only using part of the spec, but it's not trivial and probably not "reasonable" if it is just incidental to your main application development.
You will still need to consider how to protect your resource servers when they are accessed by an application which has obtained a token from the authorization server. In other words, they need to be able to check and understand the token that is issued and make an access decision based on it.
Related
We are developing a Java based product. We need to make the authentication part to fit for major authentication services, like LDAP, OpenID, Oauth2, SAML. The idea is, when we deploying the product for a company who is having LDAP, our product should be able to cater it. If the company has OAuth2, then our product should be able to cater that as well.
I want to know, what are the better approaches and tools. I'm looking for a open source solution which support all these protocols in one place. Please share the knowledge.
I'd suggest Spring Security. It is completely independent to the Spring Core framework and with some simple configuration and some additional libraries (also developed by the same team), you can get a simple solution for most of the popular authentication methods.
With a couple of annotations, you can configure which methods or endpoints you want secured either.
You can create spring profiles, who decide which authentication method to be used.
Simple approach is to use an IAM (identity and access management) solution. Kecloak is a good open source one (and is written in java but you shouldn't mind).
By the way, your question is off-topic (recommending software or tools). Post it here
You need to separate out Identity repositories and Identity protocols.
LDAP and AD are repositories.
OpenID, OAuth2, SAML are protocols.
You need an IAM system that handles all the protocols and sits on top of the repositories.
For your product to talk to your IAM, you need a protocol stack in your product e.g. for SAML.
You then federate your IAM with other vendors e.g. if a vendor comes along and wants to authenticate with their AD, they would install ADFS and then ADFS federates with your IAM system.
So the logical flow goes:
User --> authenticate on their IAM --> trusted by your IAM --> access to your application granted.
You could also look at Identity as a Service e.g. Azure AD, Auth0, Okta etc.
I am about to start developing a REST service and security is an important aspect of this project but I can't find some definitive information on how to implement it. My service will be consumed by an Android App at first, but could be used by other platforms later. Controlling user access is critical, so Authorization and Authentication control of the REST services is very important.
Although I can find topics on how to make a secure REST API, like here, here and this big one here, to my surprise, all of them fail to point to a famous standard or framework or time tested solution, which usually is the "way to go" in securing software applications, where we avoid as much as we can to "roll your own security solution".
So far on my research I think OAUTH 2.0 (or even OAUTH 1.0) is the best way to go, it's a public widely used protocol and supports Authorization and Authentication and we can control the lifetime of keys and even have a special refresh key allowing the client to not store password information for acquiring a new key if needed.
I also think Apache Shiro is the best framework for Security, Authorization and Authentication in java, so it comes to a surprize for me when I can't find any integrations between Shiro and OAUTH 2.0...ok there is one that's 5 years old, and doesn't inspire much trust to me.
Even more curious is the fact that Les Hazlewood, the Apache Shiro PMC Chair, owns (ok, owned, he just sold it to Okta) Stormpath, a company made for Identity and User Management, so I would expect him to have provided some easy integrations between OAUTH 2.0 and Shiro, unless this would disrupt Stormpath business plan too much I guess (which I don't believe, since the Apache Foundation won't allow this kind of behavior).
So the final questions are:
1 - Are there any easy integrations between Shiro and OAUTH 2.0 or will I have to code my own?
2 - Does everyone implement their own OAUTH 2.0 solution for dealing with REST APIs access control or am I missing something?
I know the Buji project uses Shiro and supports Oauth2. I haven't used it, but you can check it out.
You definately don't need to code your own. There's some great java libraries and apps that you can use for oauth2 and you can choose from a low level library that you use to build your own oauth2 server up to a full featured standalone openid connect server.
Spring security provides oauth2 that you can use to embed an oauth2 server in your application. A tutorial is available at http://www.baeldung.com/rest-api-spring-oauth2-angularjs.
There's mitreid openid connect https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server, which has a war overlay that you can use to add a user and client admin app into your webapp.
Keycloak (https://www.keycloak.org/) provides a full featured standalone openid connect server.
I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
Oltu - Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 question seems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
Spring Security - It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.
I appreciate your suggestions or feedbacks on this approach.
Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
**UPDATE** for the update of the question
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
Introducing custom authorizers in Amazon API Gateway (AWS Blog)
Enable Amazon API Gateway Custom Authorization (AWS Document)
Amazon API Gateway Custom Authorizer + OAuth (Authlete article)
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.
I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself!
Have you considered using jersey own OAuth (already linked inside jersey) server / client ?
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)
I was trying to learn JAAS, then i came up with the terms SAML and Realm, and now I am confused.
In any of the basic tutorials of JAAS, we are pretty much configuring the basic that a normal Realm configuration is. If I read configuration of SAML then it looks similar as JAAS. I have absolutely no idea why different names. May be SAML is built on Realm and JAAS on SAML, not sure can any body please clearly state the difference.
Please a humble request if you share any link, Please define a bit of it, so that it help me when i am reading them.
I have successfully configured, JAAS's BASIC and FROM based authentication on both JBOSS and Glassfish. It helped me to protect my JSP and Servelets (Web Project). where to look if I want to protect an EJB as part of my application.
JAAS is a set of standard APIs for Java SE and EE which provide basic ways to achieve authentication and limited authorization. The typical use of JAAS for authentication is through LoginModules. Implementation of a LoginModule interface (javax.security.auth.spi.LoginModule) is able to authenticate user based on credentials provided by the caller in CallbackHandler. Most application servers allows you to plug-in your own LoginModules. Other key concepts of JAAS are Subject (a collection of information about a user) and Principal (a single attribute of a user - an ID, a password). Capabilities of JAAS for authorization are rather limited and are rarely used directly.
The standard authentication mechanism for Java web applications (like FORM, BASIC or DIGEST declared in your web.xml descriptor) typically delegate verification of the provided credentials to the configured JAAS LoginModules.
Realm is a concept used to denote separation of authentication and authorization policies for different applications/systems. E.g. if you want to authenticate users in application A using LDAP and applicaton B uses database table, you can put them into different security realms, so that their security requirments are isolated and correctly enforced. The typical system which uses this term is Tomcat, but you will find similarities in othe containers/application servers too. In most cases (e.g. when depoying a single application) you don't need to worry about Realms too much.
Java EE provides standard mechanisms for securing of EJBs using role based access control (RBAC). You first define which roles are applicable to your application, then define which users accessing your application belong to which roles. You can then use either declarative authorization (= annotate your methods with security annotations such as #RolesAllowed, #PermitAll, #DeclareRoles, or do the same using XML descriptors) or programmatic authorization (= test whether user belongs to a role by calling isCallerInRole on EJBContext directly in your code). A basic tutorial can be found here http://docs.oracle.com/javaee/6/tutorial/doc/bnbyl.html
SAML is a very different beast from the previous ones. In a very simplistic way you can see SAML WebSSO as an authentication method. Generally SAML is a standard which defines an XML-based protocol used to transfer information about users, their authentication events and security attributes between remote systems in a secure way. Apart from the protocol itself SAML standard defines typical use-cases for the protocol, the most common being Web Single Sign-On (a possibility to authenticate user externally from the application at an entity called Identity Provider and login to an application - Service Provider without revealing user's credentials to it). In these use-cases SAML is similar to OpenID or OAuth 2.0 authentication you can see provided by Facebook or Google to 3rd party developers.
Hope this helps,
Vladimir Schafer
See if this helps you. A realm is a area where a specific configuration is in place. JAAS and SAML are both authentication modules that can be configured to handle authentication on that reaml. SAML is an authentication scheme. http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
To add to the other answers, I found the following explanation from this article to be helpful:
In reality, SAML and JAAS are two distinct security frameworks. SAML is an XML framework for exchanging authentication and authorization information. SAML provides a standard XML schema for specifying authentication, attribute, and authorization decision statements, and it additionally specifies a Web services-based request/reply protocol for exchanging these statements.
JAAS, on the other hand, through implementation-specific login modules receives information about the user, authenticates the user, and verifies that they are a valid subject.
So as I understand it, JAAS can be used to implement custom authentication and authorization for your app, and there are many possible ways to do this, some of which involve SAML. For example, you could use SAML to get the user's identity and role/group information; this would be stored in XML tokens that your JAAS module would need to parse.
I am currently trying to implement a single sign on solution across multiple JVM based (Grails, Servlets) web applications currently all deployed in the same servlet container (currently Tomcat, but don't want to limit my solution to just Tomcat). All web applications share a common database.
I've looked at various options from using CAS or other third party libraries to creating a new web service to handle Single Sign On, but none seem to really satisfy the business. My current implementation involves creating a new jar library which has a common implementation of AuthenticationProviders, and Pre-Authentication Filters based on Spring Security.
In this approach I have multiple AuthenticationProviders (currently Active Directory, and Database) for the application to authenticate against. Upon successful authentication a row would be inserted in a session table that contains the user, an expiration time, and a token. The token would be also stored as a cookie on the user's machine and that would be used to validate they have a current session in the Pre-Authentication Filters.
Having never done this before I want to make sure I'm not creating a huge security problem, and I'd also like to know what I would need to create the token? At this point a simple GUID seems to be sufficent?
Currently we are working on Spring Security 3.0.x, and haven't upgraded to 3.1 yet.
Thanks in advance.
I ended up solving this problem by doing the following:
I created a AuthenticationSuccessHandler which would add a cookie to the user's session which had identifying information as well as the hostname to try to secure it as much as possible. (The application was running internally at most customer sites so the risks here were determined to be minimal, but be careful about cookie jacking.)
Then on each application that needed to have SSO I implemented a AbstractPreAuthenticatedProcessingFilter, and placed in before the authentication filter which would pull the cookie out and create an Authentication object. Lastly I created an AuthenticationProvider which validated the information from the cookie.
Hopefully that helps someone else in the future for this type of request.
There are extensions available for KERBEROS, OAuth and SAML available on the Spring Security Extensions website. Here is the blog entry which provides an example: SpringSource Blog
If you are using NTLM as your SSO Provider, take a look at the jespa-spring project.
Or you might want to look at the Java Open Single Sign-On Project