I'm setting up a configuration using CAS 6.0 and Spring Boot with Spring Security so as to shift to JWT. Looking at this guide, I've configured module dependency, CAS Service Registry, and signing and encryption Keys. The flow goes fine:
calling the app at https://localhost:9000/secure/home/test I'm redirected to CAS login,
at https://localhost:8443/cas/login?service=https%3A%2F%2Flocalhost%3A9000%2Flogin%2Fcas I can correctly specify credentials and see TGC in JWT form inside the cookies,
after inserting credentials I'm redirected to https://localhost:9000/login/cas.
Last call has the two query string parameters redirect=true and ticket=[JWT string].
I've set up a filter decoding the token and it works, but then the filter chain hits CasAuthenticationFilter, which sees the ticket parameter and tries to validate it as Service Ticket, failing.
How can it be made aware of jwt, and forward the request to the original URL?
the same question in CAS 5.3.x.
finally I did the following flow:
CAS Server:
set up the cas.properties in cas server, add 'cas.ticket.st.numberOfUses=2' to let service ticket can be used twice. (default value is 1)
Application Server:
set up a filter to decode JWT token, extract service ticket from the key "jti" in JWT token.
set the response status to 302 and redirect to the request url and make the service ticket as query string named "ticket". (note that in this step should not go on the next filter)
the redirect request from #2 should not process in #1's filter then go on the filter chain.
The above flow works. But need more testing to confirm the working fine for web applications and result api service.
Related
I am using spring authorization server for oauth2 authentication, with resource server configuration for handling authentication outside of the server. My use case is as follows:
user makes a request to authorize end point
since the session is not authenticated, system caches the request and redirect the user to an external end point for authentication.
Once authentication is successful external system creates a short lived jwt token.
Jwt token is sent to authorization server, which it will validate and redirect the request to the saved previous request (which is the authorize end point call in step 1)
Since the jwt token was authenticated, I want the authorize call to succeed this time.
With spring version 5.6, the securitycontextholder was able to save the authentication, and any subsequent requests in the same session was able to use the jwtauthentication. Now since the transient check is added on the HttpSessionSecurityContextRepository.java, jwtauthentication is not saved between requests and my functionality is broken.
How can I handle this scenario? I would like to use the jwt authentication from an external source in conjunction with spring authorization server. Any suggestions are appreciated.
I already have checked a similar question- JwtAuthenticationToken is not being saved to HttpSessionSecurityContextRepository after upgrading to 5.7 version which didnt have any inputs. I also have checked the github discussions for both spring 5.7 release and authorization server 0.4.0 release and was not able to find any guides.
I have a spring boot app where the API #Controller endpoints are secured using a token that is contained in the http header. The token needs to be extracted from the header and validated against an internal cache to make sure it is valid. If the token is valid then the request can proceed to the controller and if it is not valid then it should return a 401 to the caller.
I also have another requirement to secure some of the actuator end points. When the user tries to use the browser to access the respective actuator endpoint, it will check for a user session if no session exists then the request is redirected to the spring login page. When they login I need to extract the username and password and validate using an external service. If valid a session can be created for the user and they can then use the hawtio endpoint. The session needs to store role based information so that when the user tries to perform JMX operations it will only allow them to perform the appropriate read only / write if they have the requisite role.
Any pointers regarding how you'd try and tackle this would be most welcome. I am unsure whether this is achieved by specifying addFilterBefore or addFilter and I don't understand how having authenticated the user for the actuator I go about creating a session that can be stored in the context and checked later on for subsequent requests.
Thanks
There are two spring-boot apps.
client
resource-sever
there is dev okta account that is used as auth server
(those 2 apps are standard Spring Boot client -> resource-server, almost out of the box with okta setup for them, should not be problem there)
client - securely sends messages to--> secure-sever (passing the access token in the header as prove that it's authorized to call it and get data back)
(it works as expected)
But I am trying to figure out what's going on between all them, traffic wise
I'm trying to spot that moment when resource-server checks the token it got from the client that got it from the auth server.
Here is a sequence diagram of standard oauth 2.0 flow and that part that I want to debug (arrow)
auth server
And there is a communications between client, resource-sever:
There seems I can not confirm that Resource Server (from the right) does any token validation with the auth-server (okta)..?
Question: is why? From my understanding it is supposed to validate it (somehow).
I was expecting to see a call from resource-server to auth-server (otka) with the token-validation-request (ETF RFC 7662 in October 2015) like this:
How to validate an OAuth 2.0 access token for a resource server?
I was expecting, lets say, tat for every client call, resource server would check if that token the client passes is valid. Yet I do not see any calls from resource service to okta that would use the token in its requests to okta.
This comes down to the difference between JWTs and opaque tokens.
It looks like your application is using JWTs, based on the calls I'm seeing to /keys.
When using JWT authentication the resource server will query the jwks_url (in this case /keys) on startup to retrieve a set of public keys that it can use to validate the JWT-encoded bearer tokens.
Then, when the resource server receives a bearer token in a request from the client it will validate its signature against a public key obtained from the jwks_url endpoint.
This means the resource server doesn't have to query the authorization server on every request.
You can read more about this process in the OAuth 2.0 Resource Server JWT section of the Spring Security reference documentation.
The question that you linked to refers to opaque tokens.
In this setup, the resource server must call the authorization server introspection endpoint to validate the token every time.
You can read more about this process in the OAuth 2.0 Resource Server Opaque Token section of the Spring Security reference documentation.
I have a Spring Boot application and use the Java Apereo CAS Client (version 3.6.2) to use an CAS server for authentication. In other words, I want to turn my app into a CAS client, I didn't set up the CAS server myself.
I checked the list of calls made to CAS server:
The first call to the CAS server is made, but I don't see the second call to the server for ticket validation (i.e., a call to https://cas-server-address/cas/serviceValidate URL) that will return an XML document with user and authtype attributes that I want to extract to store in the database.
I have 2 questions:
Why there is no second call for the CAS server for ticket validation? Is it hidden?
How do I extract user and authtype attributes from the XML document and store them in the database?
Why there is no second call for the CAS server for ticket validation?
There is. The second call is a back-channel call from your application server over to the CAS server. By definition, this is not something you would see in your browser. This call goes over to the CAS server behind the scenes to validate the service ticket received in the first leg (i.e. ST-xyz). The Java CAS client library should be automatically doing this for you, and you can verify this in the logs.
If you don't see this happening, your configuration is not set correctly or there is an error along the process.
Is it hidden?
Hidden from the browser, as it's a back-channel call. For additional details on what happens and why, please study the CAS protocol.
How do I extract user and authtype attributes from the XML document and store them in the database?
The Java CAS client library typically extracts the user id and other attributes. Then, the user-id would be available under the REMOTE-USER header that can be fetched via the http request object. If you have access to the http session, you can also fetch the final Assertion from the session which contains the CAS payload:
var assertion = (Assertion) session.getAttribute(AbstractCasFilter.CONST_CAS_ASSERTION);
For a more practical example, see this.
I know this question asked many times but I did not get answer that I required.
I want link that can help me to create a spring security framework, In which I donot whant login form validation.
It should be done by login RestAPI. I just hit url like-
http://localhost:8080/login
post request containing username and password and it return json response with sucess or failure status
if sucess I would be able to hit secure API Requests.
I am using spring and spring security since 1 and half year with spring security to develop rest API I use below technique for user authentication
Follow below steps
Allow to access http:// localhost:8080/login for all user
User will pass username and password in body
Authenticate user with database entry
create access token and send back to response
using this access token user with interact with secure API.
I will provide source code if you need.
I suggest you to try with Basic Authentication. I believe Rest services are mutual contract between the consumer and provider, so re design your service to access the basic auth header. Your client need to pass the base64 encoded value of username:password, Your service should get the header value and decode you will get the original data back, Check against your backend storage (Ldap or DB).
More about basic authentication . BasicAuthentication