I am having difficult integrating with SSO with my web application.
I have an sample dropwizard application.
I tried integrating with google and facebook open connect.
I thought of 2 approaches for integration
1. fetch the token from frontend js once the user is authenticated using open id, pass that token to the dropwizard server as cookie.
2. fetch the token from the dropwizard server itself and store the set token in cookie while responding to the frontend.
I am not sure on which of the above 2 is best or is there any recommend way of integrating with the open connect in dropwizard?
I like delegating SSO to well known applications/ libraries specific for the job. Keycloak is the application I’m familiar with. But I suppose some of the points below are application independent. This partial answer is a possible direction of a solution, but I don’t think it’s the recommended way, if there is any such way. Some people will dislike the approach.
The front end is responsible for authentication. But it cannot be trusted to be unmodified since it is in user space. Therefore calls to the back end should be validated for validity and authorization (which should be a back end task anyway).
Keycloak has libraries for well known front and back end implementations that allow easy integration. I’ve used it successfully with Angular and Dropwizard.
Integration with various identity providers can be combined. Therefore it is probably a pretty safe bet for a situation where authentication demands are expected to change. It takes some getting used to the extra layer though, so your mileage may vary.
Some links:
https://www.keycloak.org
https://www.npmjs.com/package/keycloak-angular
https://www.keycloak.org/docs/latest/securing_apps/index.html
Related
I am currently developing a REST-application which needs to be very scalable. From what I have learned about load balancing, one should split up the actual application into independent parts. So far I've separated creating accounts and the login from the actual application. I followed this tutorial to implement JWT. Is that best practice or can this solution be improved?
However, I have my actual REST-application as a separate project. Obviously, these two applications need to work together. How can I accomplish that? Is there a way to store the Token & access it in the second application?
Someone told me to follow microservice architecture according to this tutorial.
I really appreciate your help!
With the JWT pattern as described in that auth0 blog, the services are designed to be stateless. In fact, the example code explicitly disables the Spring session. All information required for authorization are fully contained in the JWT token itself and cryptographically protected.
Therefore, there is no need to store or share the token between multiple services / applications, as long as they are all configured with the same SECRET. Each load balanced service simply needs to verify the token received by the client, using the JWTAuthorizationFilter class.
From a best practice perspective, instead of "manually" issuing JWT tokens from each service, consider using an oauth2 or OpenID Connect service. This can be your own service, or you can use a 3rd party service such as auth0 or okta. (OpenID Connect is an extension to oauth2).
You can read more about oauth2 from https://auth0.com/blog/securing-spring-boot-apis-and-spas-with-oauth2/
Our project consists of Java back end(spring web application) and iOS and Android client applications. Now we need to add an authentication for client applications to Java back end. The idea is to register user for the first time using an external web service. At this step user provides full credentials(login and "big" password) and chooses some PIN for further authorization. After that primary step is complete successfully, user should be able to authenticate using his login and PIN(which he chose previously himself). Those login and pin should be stored in our DB. We should also be able to destroy that "session" and PIN whenever is necessary. We expect web application to have up to 10 000 registered users with up to 1000 users being online simultaneously.
We also don't plan to use any separate Authentication server, we plan to embed security into web application(back end) itself.
I've been investigating 2 different approaches. First is usual spring #EnableWebSecurity approach. This seems pretty straight forward, but some people say it will create "sessions", which are bad for the server. Session will consume lots of memory, and overall impact on performance will be bad. Is it true?
The other approach is to use Spring Oauth2 implementation. I didn't have time to study it properly, this seems to be a little bit of an overkill to me. Is it worth to study for our needs? (we are running out of time btw).
I also need to have some proper DB sctructure for the security needs.
So the question is, what is the best approach for our situation? Are there any open source projects, solving similar issue? I would appreciate any help.
Thank you.
Whatever technology you use for authentication, you will require sessions to maintain the state of authenticated user. You can use Spring security alone or with Oauth2 .
I'll suggest for simplicity you can go with Spring Security with Token functionality.
However you can find an good blog over Spring Security and Oauth.
Securing REST Services with Spring Security and OAuth2
For more clarification you can also visit here
Sessions should only take up allot of memory if you were to store large amounts of data in the session. So long as you don't do that there won't be any problem. You will need to make your own authentication decision based on your acceptable levels for security and user experience, there is no one 'right' answer. Spring security and sessions have already been talked about here How can I use Spring Security without sessions?.
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 need to make simple CRUD application with user registration and authentication using Spring boot, but I have some trouble figuring out how to do this right. I have created user table at RDMS and set up Redis for storing user sessions as explained here.
At Spring boot docs it's said that
If Spring Security is on the classpath then web applications will be
secure by default with ‘basic’ authentication on all HTTP endpoints.
But I defined several CrudRepository intefaces and after starting my application I can GET it's data using browser without authentication. I thought that it should work out of the box without additional tuning and therefore checked if Spring Security is on the classpath with gradlew dependencies command and it appears to be there:
Also default user password that should be displayed during application start up does not show up. So maybe I am missing something here?
Also I am not sure if that would be the best option for mobile app because it possibly uses short-living tokens. There are several other options, among which using a WebView and cookies (as was recommended by Google long ago), creating a custom authentication entry point, using approach that was used in Angular web app and finally stateless authentication with OAuth 2.0. Directly in opposite to author of Angular web app tutorial who claims
The main point to take on board here is that security is stateful. You
can’t have a secure, stateless application.
So how do we need to pass token? How long should it live? Do we need to make additional XSRF token or not? Should we use out of the box solution or implement own one? Can we make it stateless?
I'm looking for some advice on the simplest way to create some product registration communication. I have a Java desktop application that needs to be re-newed every year. When a user downloads and install this app (through JNLP) they get a limited demo-version. There is code in place on the client to "register" the product and unlock all of the features.
My next step is to build the server-side components. There will be a database with customer ID numbers and other information about the customer. When the user clicks register, some contact information will be sent to the server as well as some product registration ID. The server will check this against the database and then either give the client the o.k. to unlock the features or the user will be informed that the registration id was not valid. This seems like a very standard thing. So what is the standard way to do it?
I have my own VPS and I'm running Tomcat, so I'm really free to implement this any way I choose. I was planning on building some web service, but I have never used REST before.
Use REST; REST is nothing more than using plain HTTP 'better'. Since you are already using HTTP, somehow you are already doing REST like calls and moving these calls to full fledged REST will be easy.
Implementing REST calls is easy. You have two approaches:
Low end: using URLConnection objects on the client, servlets on the server and following some REST conventions on using HTTP methods and 'clean' URLs (see here). Advantage is that you need no 3rd party library and minimize the footprint. Maintenance and evolutions are harder though.
High-end: a framework and specifications like JAX-RS. Using Restlet you can be up in running with a REST server in a couple of hours without having to deploy a servlet container.
Don't use SOAP. The only reason you would want to use SOAP is that you want to contractualise using a WSDL what you are exposing (you can do the same with REST btw, see the Amazon documentation for instance). Trust me, SOAP is way too heavy and confusing for what you are trying to do.