We have a Java 8 backend application using SprintBoot with an embedded Jetty server.
The UI for the application is a Single Page Application built using React.
Currently I have enabled authentication by integrating with Okta using the spring security SAML extension. When the assertion is posted by Okta to my app, I create a session and the JSESSIONID is sent in the cookie.
This was fine until now when we had a very simple UI serving few UI components.
However, now we have several REST endpoints in our backend and we would want them to be authenticated as well. REST endpoints themselves are developed using Jersey.
If I understand correctly, SAML is clearly not the choice for pure REST based endpoints as SAML is mainly a browser based protocol. These REST endpoints will be called by our UI as well we want them to be independently called via Postman or something for testing.
When a client would call these REST APIs, I am guessing the client should send an Authorization header which should be checked by one of the authentication filters in the backend. After validating the client and the user, the filter should inject the user information in the SecurityContext because Jersey injects SecurityContext in all of the REST endpoints. Then it becomes easier to fetch the user from this SecurityContext.
Upon reading, it seems Okta OpenID Connect can be one choice which issues a JWT. However I am not clear on how to use this. That is, when Okta issues a JWT should our UI or any client for that matter keep sending the JWT in the Authorization header to our APIs and then our APIs in turn should send the JWT to Okta to validate it?
Question is what is the best choice to serve both, a login for the UI and a session and authenticating REST endpoints? Not to mention the REST APIs will be stateless in nature.
When a client would call these REST APIs, I am guessing the client
should send an Authorization header which should be checked by one of
the authentication filters in the backend
In OpendID Connect (OIDC), that value in the Authorization header is id_token which can be in JWT format. This id_token is issued by the OIDC server as the last step for whichever OIDC grant type you choose and applicable to your case.
Upon reading, it seems Okta OpenID Connect can be one choice which
issues a JWT. However I am not clear on how to use this. That is, when
Okta issues a JWT should our UI or any client for that matter keep
sending the JWT in the Authorization header to our APIs and then our
APIs in turn should send the JWT to Okta to validate it?
Think that you have 3 components in this architecture. Relying Party (client), Identity Server / Authorization Server / OIDC Provider and Resource Server (your backend and it's data). When Authorization Server issues and id_token to Relying Party, your Resource Server also knows this token. So when you request for data in resource server, you will present your id_token to Resource Server and it knows if it is valid id_token or not
Question is what is the best choice to serve both, a login for the UI
and a session and authenticating REST endpoints?
OIDC Provider (or Identity Server if you need more complex operation), since OIDC is Authorization (OAuth 2.0 at core) and Authentication.
Related
I’m developing a spring boot application where users can register into the system by providing the necessary information. The platform should provide users to authenticate with their registered user credentials or social media login credentials (google/Facebook).
For simple user authentication, I want to create a simple post request to the server with the user name and password and after validating, the server returns a token. I do not want to use the spring security form login here.
But for social media logic, I believe I have to go with oAuth.
I’m new to spring Boot and spring security. Do I need to integrate both JWT authentication and OAuth authentication for this scenario? A suggestion would be highly appreciated
What you. describe about user management (user registration, login, logout) are standard features of OAuth2 / OpenID authorization-servers. You should pick one "from the shelf" either on premise (like Keycloak) or in the cloud (like Auth0, Amazon Cognito, and many others). Many solutions include "social" identities federation.
REST APIs are resource-servers. See those tutorials for security configuration and tests with mocked identities.
UIs are clients. You should use an OAuth2 client lib to handle OAuth2 flows. Find one for your framework Spring has one if your UI is generated on server with Thymeleaf or alike, but there are libs for Angular, React and other frameworks running in browsers.
Spring OAuth2 client libs can also be used in BFF (backend for front-end) scenario when browser client is not OAuth2 (it is secured with session, not access-token) and talks to an app on the server which is the OAuth2 client (spring-cloud-gateway is a sample but you could also write your own app with spring-boot-starter-oauth2-client). This app translates the request with session into into one with access-token before forwarding it to resource-server. The aim is to hide tokens from Javascript in the browser.
We use Keycloak to secure our Spring Boot based Java Backend Services. Every endpoint is secured and a bearer token is expected inside the authorization header for each request. Keycloak then validates and verifies the token. So far so good.
During the registration process inside Keycloak (we use the authorization code flow), we have different use cases in which Keycloak have to approach our Java Backend for instance to validate an access code. I would love to use the same mechanism to secure those endpoints that are exclusively approached by Keycloak. I am wondering if it is a bad idea to use a keycloak user to send an http from a keycloak spi to our spring boot backend and then ask keycloak if the given JWT is valid. This feels like a chicken egg problem.
This feels like a common problem. What is the recommended authentication/authorization process for this kind of service to service communication? I was thinking about a technical keycloak user, that is managed inside keycloak for this purpose. I am aware of the Keycloak REST API that provides an endpoint to retrieve a token for credentials. Since I am implementing custom SPIs in keycloak, I am looking for a way to generate a token programmatically. I was able to find the right Keycloak library. Does someone know how to do that?
Here are my question:
How can I secure requests that I would like to send from keycloak to our backend?
How can I generate a Token inside Keycloak without using the Keycloak REST API (since I am implementing custom Keycloak SPIs)
Is there another way to secure my backend for technical users without using keycloak?
Best regards
Michel
I'm developing a backend server for my applications. Actually, I'm using Keycloak as Identity Provider exploiting the OpenID Connect protocol. The frontend redirects users to Keycloak Login Page, so a token is returned to it. The frontend makes an authentication request to the backend using the returned token. Backend asks the IDP to validate the token and retrieve user info and roles.
Then I want to generate a JWT from the backend in order to easily authenticate the frontend requests.
Is this architecture fine? Or am I missing something important? Can I implement this architecture using Spring Security? Where can I learn more about it?
Thanks for any advice and support.
I am struggling with SAML based authentication for SOAP Web Services from last couple of days. I have gone through tons of tutorials to understand the concepts and setting up SAML authentication in my local environment. However, I am not getting couple of things on it.
I have created and hosted the web services and written consumer to access those services (With Java). I have also set up OpenAM to act as Security Token Service (STS)/Identity Provider (As described in most of the tutorials).
My understanding on SAML authentication for Web Services are as below:
A Web Service consumer should authenticate itself with some means (e.g. credentials) and get a SAML response token with certain assertions from a Security Token Service (STS)/Identity Provider (IdP).
Service Consumer then present the SAML token to the Web Service it is accessing and based on the authentication, web service will decide to access/deny.
I am not able to understand following things:
How can I configure OpenAM correctly as STS/IdP. Most of the tutorials I have seen on OpenAM are focused on Single Sign On (SSO) and configuring IdP/SP for the same. Also many of them are on LDAP context.
What changes I have to do in service consumer so that it will request for a SAML token before accessing the services.
How web services will validate the SAML token and allow the consumer to access the service.
I am building a RESTful Webservice using Apache Jersey. Now I want that you need an authentication for some requests to it. Using the typical REST-approach the Authentication should be done via HTTP-Authentication. But a post here mentions that a better way how this can be done is by using cookies. I think there are some valid points in the discussion. (How) Can I make my Jersey Authentication work with Cookies? Do I need another framework for it?
Jersey uses the authentication mechanism declared in the enclosing web application's web.xml, practically either HTTP Authentication (over SSL) or Form-based Cookie authentication.
If you want to used cookie-based session authentication, users must authenticate with the web service first to create a session which can be used to check their identity for future calls. The servlet spec provides a standardized way to authenticate using cookies and session using a web form, which however, is not compatible to a web service type of application. So you would probably want to cook up some custom solution to let users submit their credentials via POSTing an XML or JSON document. A problem with this method is that if a user performs a call to a resource without first authenticating or after the session has expired, they will need to be redirected or receive some type of error code. Not impossible but it adds complexity to your web service.
At this point you have to wonder if using HTTP Auth is not the better choice for web service style apps. We recently built a web service using Jersey and HTTP Auth as the authentication mechanism. We then build a Javascript front end on top of it. The Javascript client always submits the Authentication headers to the web service so that the user is never confronted with the HTTP Auth authentication window from the browser. Perhaps the best of both worlds.