I've used Keycloak for authentication in services that are consumed only by web browsers, but now I'm facing the problem of building a JAX-RS application that will be consumed by native mobile apps on iOS and Android.
Keycloak provides a lot of the features I need, like: built-in support for combining multiple social logins and LDAP and/or Kerberos, self-service user registration and excellent management of authentication tokens and roles for different applications.
I'm aware of libraries from Aerogear that would allow me to add Keycloak to a mobile app, but I have a few concerns:
Aerogear doesn't implement an AccountManager+SyncAdapter on Android. This seems completely wrong and makes me want to use something else, but I'm not aware of anything else that is designed to be quite so "plug and play" with Keycloak as Aerogear's Authz.
If I implement my own authentication and authorization mechanism, I end up needing to do a lot more testing in order to ensure security of services and lose a lot of the benefits of operating in the Java EE environment to begin with.
What is the best way for me to implement native mobile access in Java EE 7? If it helps, I'm using Wildfly 10 and most clients will be on Android with some on iOS.
UPDATE: The best option I've found so far is to use an offline access token with Keycloak accessed with a custom account manager+sync adapter. Is this the best solution for me to go with?
Related
I have an application which is built using Spring MVC and the backend is REST API also built using spring MVC framework.
The request from the browser first hits the springMvc app which then calls my REST API for data. I do not have any needs to expose my API's publicly. So I am not thinking to use any API gateway.
For security, am thinking to host my REST app in a private subnet and host the springMVC app in public subnet in a VPC.
My question is what if some developers would like to test the API's directly , what provisions are available in AWS to manage this in development environment.
I am using AWS cognito for authentication and am just going to validate the token in the REST app for additional security. At netwrok level, I am planning to use Netwrok ACLs to restrict the REST app to be only called by my springMVC app. Basically one public subnet and one private subnet.
Please help if my understanding is correct in this regards and would it cause any design issues later on.
If at some stage later, I plan to expose my API's to lets say a mobile app, I might have to do some rework. Is it worth it to think about future now and design accorindgly considering it might not take much time if I am on AWS.
You can use API Gateway to create private APIs that are only accessible by your VPC. You should consider using this option if possible. There are a lot of things that are difficult to manage when it comes to APIs such throttling, caching, and logging. Using API Gateway a lot of the scaffolding and instrumentation work for the API will already be done. You can also connect Cognito user pools to the API Gateway.
This blog post has a good overview and an example.
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. :)
We have a Java web application (using struts and hibernate) and want the users to automatically log into the Google apps domain accounts.
We have set up the Google apps for Education domain accounts and created the users in it and we have the same users in our java web application also.
The requirement is that when the users log into our application portal, their is a link to go to Google apps, once they click on this link, it should log them in without asking for password.
We are using Tomcat 7 as our server for the web application. Which SSO tool should we use for doing this? Oracle's SSO is paid, Shiboleth doesn't work with Tomcat 7.
Any help highly appreciated? Is SSO the only option or another way to do this.
Thanks
Any SSO solution that supports the SAML2 protocol should work. Apart from the expensive solutions that Oracle, IBM, CA and others provide, you can find the following solutions that definitely work well with Tomcat7 and are open source :
Apereo (ex Jasig) CAS : Used quite a lot in the education community. Simple to setup but specific configurations (like an advanced authentication module) might require some programming effort. It supports Google Apps authentication, but none other SAML2 service. If you really want to only login to Google Apps, that's a great and simple solution.
Forgerock OpenAM : Formerly Sun OpenSSO, this is used in education and industry. Many more features, supports most of the SAML2 service providers out there including Google Apps, but more complex.
Note that if you already have a portal solution, you should check if that portal does not already support SAML2 federation and could act as the SSO server.
Note also that you will need to link the portal authentication and the SSO server authentication, to make sure that your users do not authenticate twice. This can be done in two ways :
Tell the SSO server to delegate the authentication to your portal solution. This might require some light custom coding depending on your portal.
The opposite : tell the portal to use the SSO as an authentication solution. Most portals support some kind of authentication delegation so it should only be configuration?
Lastly, if your authentication is setup on Tomcat itself (that is if your portal already delegates the authentication to the Tomcat container), then you can do the same for the SSO server.
I am using ActiveMQ to connect a number of application modules written in Java.
I eventually would have a web interface for the application, developed in either Grails, Struts2, or Rails.
My 2 main concerns are:
to have an external security module that is not bound to the Web Framework in use.
to have an independent security db
Any recommendations for this Architecture?
You should place all your components within a secured firewall. Then you wouldn't need to worry about any kind of security for ActiveMQ. If not a firewall, you should have a way to whitelist your components so only you can connect to them.
For the database, I recommend having one user that read data and one user that writes data. Separating this permissions will be a closer step to someone deleting you data.
You need to secure both parts of your application. For the first part go with Amir Raminfar's answer, and insure that your running on secure servers. Also make sure to use what ever security features are built into MQ to allow the components to communicate securely. For Web Security there is no good way I know of to have a framework agnostic security setup. An option for you may be Spring Security You should be able to integrate it with Struts and there is a Grails Plugin This should make it easier to do security in a relatively common way whether you use Struts or Grails but you will probably not be able to easily use Spring Security from Ruby.