I use Spring boot security for my server.
I added new filter that extends from OncePerRequestFilter and (according to many tutorials from the web) after validating the jwt save Authentication object into SecurityContext.
What I don't understand is why do I need to save the Authentication in SecurityContext? after all I validate the jwt from the client in each request and don't need spring's to call isAuthenticated() on Authentication object.
Do I miss something?
Spring Security Authentication basically works by storing it in the SecurityContext. There is a SecurityContextHolder class which stores the SecurityContext and is used to many places where Authentication/Authorization decisions needs to be made by retrieving the Authentication. Even though you have validated the JWT to check the Authentication is success, Spring Security still needs Authentication object to make other decisions for example to evaluate hasRole(), hasAnyRole(), etc.
Related
I need some lights about convenience of using an autheorizarion server in my project scope.
We're realising and deploying our services into customer environment.
Customer infrastructure already provides an authentication mechanism in order to authenticate users.
This mechanism intercepts all comunications and redirects user to a "login" form.
After that, user is redirected to our service and we've to handle and digest it and respond with an JWT token.
Here is where I'm feeling lost:
I'm thinking about:
using spring-oauth2 in order to request a JWT token to an authorization server, or
using spring-oauth2 in order to auto-generate an JWT token and validate it. I don't know if it's possible.
My question is, since user is already authenticated, have it sense to use an oauth2 authorization server, using client-credentials in order to authentication client against our resource services?
Short question would be, could I use spring-oauth2 librearies in order to generate a JWT without an authorization server?
You technically can do it, but I would discourage you from doing that. Access tokens in a system should be issued centrally, by a dedicated service. Otherwise, it will be hard to maintain the infrastructure. If your services will start to issue JWTs, then they will also have to provide the public keys for others to validate these JWTs. Keys management, access token contents management, and any rules of mapping user information into claims - will now become part of your service and it will unnecessarily complicate its implementation.
If the customer's authentication mechanism issues a JWT, why not use that one for request authorization? If that one is insufficient, I would recommend having an Authorization Server (or a dedicated service), that can perform Token Exchange and exchange the original JWT for a new one.
Spring Boot Security,
My Application is already running using Spring Security. Now I want to authenticate the users through OAuth. Is there any way to build a custom servlet to achieve this?
You can add a new Filter to intercept and authenticate OAuth requests in which it should call the authenticationManager.authenticate method and save the result of the authentication token in the SecurityContextHolder. This way the user is fully authenticated.
Note, that this way you don't "override" or "bypass" the Spring Security. You just use it to perform a different authentication.
We had an web application that already using form-login provided by spring-security, say, ERP. Now we are considering make ERP as an oauth2 authorization server to authorize other internal services.
The ERP still serving its business and all access are required to be authorized, but doesn't based on access token so I think it is not an oauth2 client. It does NOT serve as an Resource Server, neither.
I have read many article about how to setup oauth2 authorization server and develop an application using it. According to this comment I feel it is possible to make ERP authorizing other services without explicit setup a standalone authorization server (it's our final goal but not now):
Within the context of OAuth2, we can break things up according to the component you're implementing:
Client app: it's likely that server based OAuth2 Client app already uses HttpSession and therefore it makes sense to use Spring Session and benefit from all the goodies it brings
Resource Server app: since this component provides a stateless API that's authenticated against using an Access Token as a bearer, the HttpSession is not used and therefore Spring Session isn't suitable as well
Authorization Server app: it's highly likely that this already uses HttpSession so similarly like with OAuth2 Client app, it makes sense to use Spring Session and benefit from all the goodies it brings
What I'm going to do is add the #EnableAuthorizationServer into config, but I have no idea what's the next step.
My question is can I convert an existing application into an authorization server while keeping its original service unchanged? Where and How should I start?
I just found it's not that hard to integrate OAuth2 into existing system, below is what I did to make it work.
In short: EnableAuthorizationServer won't break anything exists, but they don't coming from nothing, either.
When I put on the EnableAuthorizationServer, spring-security-oauth2 gives me following endpoing:
/oauth/authorize
/oauth/check_token
/oauth/token
/oauth/confirm_access
/oauth/error
Those endpoints provide necessary functions to make OAuth2 works, and I just need to apply access control onto those endpoints with existing form login mechanism (probable not the check_token one).
Since this system didn't act as resource-server role, the authorization part is done.
From the Spring Session Rest sample: http://docs.spring.io/spring-session/docs/current/reference/html5/guides/rest.html
I have deployed the sample on Cloud Foundry and it works.
I am wondering how the session is working with Spring Security AuthenticationManager to authenticate the x-auth-token in the second request.
I checked the code in the Spring Session, but not found any details.
To my understanding, the authentication manager will look for the session in the SessionRepository by the x-auth-token.
Can someone show me how the authentication in the Spring Session Rest works?
Actually as far as Spring Security is concerned there's nothing different in this sample compared to an application that doesn't use Spring Session (i.e. uses Servlet container's internal session storage and JSESSIONID cookie).
Spring Session uses org.springframework.session.web.http.SessionRepositoryFilter to replace Servlet container's HttpSession implementation with a custom implementation backed by Spring Session. This filter also provides HttpSessionStrategy (either cookie based or, like in your sample, HTTP request header based) to correlate the information your provided (again, either via cookie or header) to the session stored in SessionRepository implementation of your choice. After that, it's all up to how your application uses the session.
Note that Spring Security's AuthenticationManager simply handles authentication requests for the provided Authentication token. It does not have any knowledge of session, or anything else web/Servlet API related.
What is the utility of remember me to spring security. Is that it is already known by spring security like j_password variable and j_username?
Spring Security Remember-Me Authentication
Remember-me or persistent-login authentication refers to web sites
being able to remember the identity of a principal between sessions.
This is typically accomplished by sending a cookie to the browser,
with the cookie being detected during future sessions and causing
automated login to take place. Spring Security provides the necessary
hooks for these operations to take place, and has two concrete
remember-me implementations. One uses hashing to preserve the security
of cookie-based tokens and the other uses a database or other
persistent storage mechanism to store the generated tokens.
I have nothing to add to that.
The server will send the browser a cookie that will be returned (until it expires). When the server sees a request with that cookie, it doesn't pop up the login page as it would otherwise do automatically with Spring Security.