I'm trying to use spring-authorization-server, and it seems to work very well, but as i can see it relies on servlet api which makes it not usable with spring webflux and netty. Does anyone knows how to tackle this? Or maybe correct me if my assumption is wrong.
thanks
WebFlux is not on the roadmap for Spring Authorization Server.
From the Spring Authorization Server GitHub repository:
We are strictly focusing on a Servlet implementation for the initial set of features that would qualify for a MVP version. We haven't decided whether we'll provide a WebFlux version at this point.
Quite honestly, I'm not convinced it's needed. The client and resource server(s) are the most active, whereas, the authorization server is not as active as it simply issues a token and may validate a token, which is limited activity between the many interactions that follow between a client and resource server after a token is issued.
Quote taken from this issue.
Related
I am quite new to spring boot, And i was asked to implement post microservice endpoint to expose to other system to post some data in db(which I have handled through java code)
And I am planning to add basic auth with some client certificates (for eg: Tls).
Here the question is when I am trying to test the above Post api through postman csrf is enabled in spring boot automatically and it is blocking. Then I have added csrf.disable() in my config method and it works. But in production ready code we cannot disable using the above method I guess I think we have to handle bit different with it. Should i have to allow domain specific?? If yes how to achieve it?? Please let me know.
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
Is it possible to forget the authentication, jwt login stuff and security for now and implement it later?
I choosed java for my restful service back-end for my game, but i'm having such a hard time setting up a simple login system with a mysql database, jwt authentication and spring boot. I followed a great tutorial, but it's only concerning Spring boot, not JWT security.
I would like to move forward and implement the security later if possible.
Right now i just gave up and i'm doing simple apis with just spring boot based on this architecture : https://github.com/djdjalas/SpringBootIn50/tree/master/src/main/java/com/yourname, i replaced the fake data with jdbc calls to the mysql database. Is it ok? Will it be hard to implement autentication later when i will have many services?
Thank you.
Spring Security itself is hard to understand and master in the way it should be done as it requires more understanding of the processes behind its configuration. Anyway, if you get familiar with it you won't have serious difficulties here. There will be no major changes to your code. You'll end up generally with one more configuration class/file and this is it.
Can't say anything about JWT but don't think it will be a problem either.
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'm pretty new to REST and am currently developing an API with JAX-RS Jersey. I am curious on what is the easiest way to implement a user Management. I.e. users must log in and have restricted access to different resources depending on their role. From what I understand, using OAuth 2.0 is the current standard. Can I implement that with Jersey? Does anyone have a few links for me to get me started (examples, tutorials)? Or would you suggest another approach?
Thanks a lot
There are multiple ways to achieve that, let me point few of them:
HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifier and login pages. Rather, HTTP Basic authentication uses static, standard HTTP headers which means that no handshakes have to be done in anticipation.
Role based access control for J2EE applications using realm
OAuth with REST:
There's an OAuth 1.0 contrib for Jersey # https://wikis.oracle.com/display/Jersey/OAuth
Works great for me. OAuth 2 is not really a standard yet as it's not finished and there's still a lot of debate and interoperability issues around it.