I have created 2 JHipster applications (JHipster v6.3.1):
Microservice Gateway
authenticationType: oauth2
Microservice Application
authenticationType: jwt
I have configured Okta with the gateway app and this works fine, I can log in with my user. I can also see that the ROLE_ADMIN and ROLE_USER authorities are being correctly assigned in Spring Security.
However I get the following error from the Microservice Application when I attempt to add/view an entity:
Unsupported JWT token.
Unauthorized: Full authentication is required to access this resource
Is there some configuration I need to do to get the JWT token passed in to the Microservice Application?
You cannot mix authentication types between microservice apps. You have to use either OAuth 2.0 or JWT in all of them. FWIW, JHipster's OAuth 2.0 support does use JWTs.
Related
I have an application set up as follows:
Angular UI -> Spring Cloud Gateway -> Spring Boot-based Service
I am attempting to authenticate my application against a limited Oauth SSO server with ONLY the following endpoints:
/authorize
/token
/userdata
The SSO does not provide an /introspect endpoint, nor does it issue JWTs.
What I would like to do is have Spring Cloud Gateway handle the authentication, but based on the result from /userdata, I would like to generate my own JWT to relay to the service.
My questions:
Is this possible?
If so, can someone give pointers or guide me to the resources that will get me started?
Spring Security OAuth2.0 Client and Spring Cloud Gateway combination works well in this case.
Client(Angular UI) requests to the Gateway service with OAuth2.0 login URL
The Gateway redirects the request to Identity Provider(Such as Google) login page.
After user login successful Identity Provider redirects the request to the Gateway with user info.
On Authentication success handler(Gateway service)
Parse user info and save it to somewhere
Create access token and refresh tokens. Set them to request cookies
Redirect to client(Angular UI)
I don't know the reason to pass the token downstream services at this point. If there is no specific requirement then I would implement all the security related operations on the Gateway service. Such as token generation, validation etc. This way new services can be easily added without concerning about authentication and authorization.
Here is a sample project.
I deployed a Standalone Keycloak (KC) server and I developed one API that acts as a resource server(it is not supposed to handle login/registration of users etc) with Spring Boot. I want this API to be secured with KC JWT tokens. I expect every user coming has already obtained a JWT token. To the security configurations of my API I added the following configuration:
spring.security.oauth2.resourceserver.jwt.issuer-uri=http://localhost:8180/auth/realms/<REALM_NAME>.
Everything works as expected, my API is able to allow only authenticated and authorized users to call the endpoints. However, I have the following question:
As my configurations are right now, anyone who receives a token from my KC server and the issuer-uri can build another API and do her/his own stuff. How is it possible to restrict the KC server in order to be used only from APIs that I allow? E.g: my API should provide a client_name and a client-secret before it is allowed to verify a token with the issuer.
I am using spring-boot-starter-oauth2-resource-server to configure OAuth2 instead of the one that Keycloak provides. I am running Spring Boot 2.4, Spring Security 5 and Keycloak 12.0.4.
Implementing SSO in my application and from app-1 i need to make a rest call to app-2. Login in app-1 with SAML and authenticated successfully and trying for rest call from app-1 with openid but since authentication is using saml only so not able to get the access/bearer token. Please help how to get the access/bearer token from saml request/response. I'm using Keycloak Server for SSO implementation.
You can't.
REST API need a JWT token not a SAML one.
Change SAML to OpenID Connect and it will work.
(1) OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
(2) Presently there is no IETF draft document regarding SAML 2.0 Profile for OpenID Connect client.
We can refer to the IETF draft document SAML 2.0 Profile for OAuth 2.0 client.
The OAuth 2.0 Access Token using SAML Assertion filter enables an OAuth client to request an access token using a SAML assertion. This supports the OAuth 2.0 SAML flow, which is used when a client wishes to utilize an existing trust relationship, expressed through the semantics of the SAML assertion, without a direct user approval step at the authorization server. For more details on supported OAuth flows, see API Gateway OAuth 2.0 authentication flows.
(3) Both Auth0 and open-source WSO2 Identity Server implement the SAML profile for OpenID Connect/OAuth to convert SAML token to OpenID Connect/OAuth token, as demonstrated by Auth0 SAML Configuration and WSO2 Adding and Configuring an Identity Provider. In other words, Auth0 and WSO2 Identity Server can relay SAML authentication provided by SAML IdP to either OpenID Connect client or OAuth 2.0 client.
I have a project in which there are several microservices which are secured using spring oauth2.I have published these services on WSO2 API Manager and disabled the oauth2 feature of WSO2 as my services are already secured using spring oauth2.Now when I access my services published on WSO2, using token of spring oauth2 i get in response either status code 0 "no response" or status code 403 unauthorized.What could be the issue here.
The WSO2AM (API Manager) authorizes the clients using the OAuth protocol and the backend services should trust the WSO2AM providing service authorization.
The API MAnager is not able (by default) validate the tokens of your backend services.
As far I know WSO2 AM clears the "Authorization" header to the backend services. (correct me when I am wrong).
your options:
Setup a proper environment, where APIM is used to authorize users. The APIM can send a JWT token to the backend services with user identity and attributes and the backend service will validate and trust the APIM JWT token containing user identity and attributes. I really suggest you stick to the way how APIM works and not try to force it working other way
If you really must using your own OAuth tokens, you could send the authorization token in different header (which will not get cleared)
You could create a custom mediation flow to to re-enter the authorization header into the request (I am not sure if you will need to update the exposed api mediation flow too or not to skip the default authorizer).
We are already using CAS for single sign on for several web applications that we are hosting. Now we are going to deploy several HTTP/REST services in our network and those need authentication and authorization.
Would it be a good idea to combine CAS with OAuth ?
Users would still use CAS for SSO, but additionally login procedure would issue OAuth ticket that would be used to access REST services.
REST services can be protected via CAS proxy authn. Additionally, they can be integrated with OAuth. CAS provides both OAuth and OIDC protocol functionality as well.
That's certainly valid. OAuth 2.0 doesn't specify/dictate how the user (Resource Owner) is authenticated and CAS/SSO is fine for that. Effectively you'd be leveraging a CASified Authorization Server so that the Resource Owner authenticates with CAS to the Authorization Server, which is "just" an application to the CAS SSO system. The Authorization Server would then issue an access token down to the Client so that the Client can use that access token to access the protected resources i.e. the REST services.