I understand the initial basic authentication used by Spring security but how does spring security
handle subsequent request to server after user has been authenticated? I mean where does spring looks up to check user credentials and not to ask the user to enter its password after each request to secure resource on server?
As for the classic session id authentication after the server sent session id to browser how spring security interacts with it and not asking for password for each request?
Related
I'm developing a microservices application that has to authenticate users against an external Identity Provider using SAML2 protocol.
The architecture
The idea is to use a SPA running in the browser which only talks to the API Gateway and uses Cookies for authentication.
The gateway delegates the Authorization Server to check if each request is authenticated and initialize the SAML2 login if not.
Once the user authenticates, the Authorization server initializes a session and sends back the cookie straight to the browser.
The Authorization Server is actually an OAuth2 Auth Server as well as a SAML2 Service Provider.
For every request coming after the user authenticated, I want internal communications to use OAuth2.
Frameworks used
For the authorization server I'm using the Spring Authorization Server package as well as SAML2 Service Provider libraries of Spring Security.
Resource services would use Spring Boot OAuth2 Server library.
What's working
I managed to set up the SAML2 client so that the Authorization Server is already generating a Session for the user after IdP authentication and I'm capable of reading the authenticated principal.
The problem
For the upcoming requests I want the API Gateway to perform a token replacement by exchanging the Cookie for an OAuth2 access token before forwarding these requests to resource services. Each resource service will then validate these tokens against the authorization server.
What I'm trying to achieve here is to make the API Gateway as a Backend-for-Frontend but the I'm struggling to figure out which authorization flow to use given that:
the client is the API Gateway, so it can be considered confidential
user credentials are missing as they are provided to an external IdP and the principal comes from a SAML Response
the authorization server has already estabilished a session for the user
Basically I can't figure out how to exchange the JSessionID for an authorization code.
Any ideas?
You should not bother about the authentication-code, the BFF (gateway configured as OAuth2 client) should receive it and exchange it for tokens (access, ID and refresh) during login process and store those in session (which should be activated along with CSRF protection).
When requests land on the gateway, session is replaced with Bearer access-token (kept in session) before being forwarded to resource-server. This behavior is activated with the tokenRelay filter in route properties (if I remember well...)
I have some microservices in Spring Boot and my front end application is in angular. I am using OpenID Connect for authentication and authorization. Right now, in my application, when the angular app is loaded, it redirects the user to the authentication server and after login the token is received which is sent by the angular application in each HTTP request to the resource servers. Now I have a question. My microservices also communicate with each other but as each microservice is acting as a resource server and the Rest APIs are secure now, so microservices can not communicate. What I want to achieve is that the requests which are sent by the user from the angular app should contain a token and those requests should be verified but I want to bypass or disable OAuth security for inter service-service communication between microservices. Is there any way to achieve this in Spring Boot?
Do not disable OAuth2 security in your micro-services:
if the inter-services request has the context of user (issued to satisfy part of an authorized request) just forward the original access-token
if inter-services request is not originated by a user request / event / callback,... (scheduled task for instance), then it is possible to acquire an access-token using client credentials flow. Authorization-server should be configured to attach required roles to each client when it issues access-tokens with client credentials flow.
In first case, you can access bearer token from the Authentication in the security context. Add this Bearer string as Authorization header to the requests to other micro-services.
In second case configuring REST client (WebClient, RestTemplate, FeignClient, ...) with client credentials is usually enough for it to automatically fetch an access-token from the authorization-server and add it as bearer header before sending requests to the resource-server.
I am trying to configure an authentication flow in Spring Boot using OneLogin SSO. I can successfully authenticate, create a JWT token, and redirect to my frontend app.
However, I am not certain of the next steps. When my JWT token expires, is the appropriate course to clear my security context and then to redirect to OneLogin again and reconfirm my authentication? Right now, as far as I can tell, Spring's security context represents one moment in time and I can't figure out how to refresh it against my SSO provider to ensure the user is still authenticated.
I have set up the keycloak server and created the spring rest application with keycloak rest adapters. The Authorizations rules are working fine.
I would like to know about the internal working of the keycloak spring boot rest adapter. How the logged in user's token is validated against policy and permission set in keycloak admin client.
You are correct, access token does not contain all these details.
In Keycloak when you are using server side adapters the client will be configured to use the standard flow and not the implicit flow of OIDC.
In standard flow when you login using keycloak IDP your front-end redirects to Keycloak IDP and asks for you credentials. If you have the right credentials login is successful and you are redirected back to your app. In this redirect your app gets a code which it then sends to the back-end rest call. This code is used by spring adapter in the spring boot app to make a call to Keycloak IDP server and it is this call in which the boot application will get the user context to take all the authorization decisions as a response from the Keycloak server.
Hope this makes sense.
I am currently usingstruts, spring and hibernate in my application. I'm using CAS for authentication. The table containing the user name and password fields are mentioned in the deploymentConfigContext.xml of the CAS war file.
Using spring security how can I implement the same in my application for web services?
How is the username and password given from a client invoking my web services?
Your WS is protected by some sort of CAS filter, that is perhaps provided by Spring Security. When a request comes in, the filter intercepts and redirects to CAS login. User logs in, and they go back to the WS. Filter intercepts the request again, validates the ticket and moves onto the WS