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.
Related
I have to build an application by using microservice architecture. I divided the whole system into multiple components and each component represents a spring boot project. There are several spring boot projects around 6. I have used the eureka server to register all the services for load balancing. A separate Spring boot project has been developed for the web portal and that application contains authentication, authorization with spring security, and JWT protocol. Now I have 7 projects including a web portal and each project has controller classes under the controller's package.
Now I need to know the following things,
SignUp and SignIn request come to the web portal and after signing a JWT token is generated and it is sent to the client but the Authorization part is only available in the SecurityConfig class on the web portal. So should I send all the requests from the client to a component through the web portal each and every time after authenticated?
Client ----------------> Web Portal ------------------>Service/Component
I need to know that can I send a request to another component/service directly like below?
username + password
Client ---------------------------------------> Web Portal
JWT token
Client <-------------------------------------- Web Portal
JWT token
Client ------------------------------------------> Service/Component
likely yes, because JWT is something available with the user and every time he sends the request, the token shall be validated by the issuer or in cases when we black list some tokens then those requests shall not be processes directly.
In microservices, the API gateways take care of these things and after checking for role and permissions, it forwards the request to the respective microservices based on the incoming route or URI which is then mapped to URI of backend service registered in Eureka server.
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.
1) Is it possible to do a SAML 2.0 SSO Interaction using an AngularJS 1.x SPA and Jersey 2.x backend web service api?
2) Has anyone done this before? I can't find too many examples.
My thoughts:
It seems like I can have certain endpoints that will http-post the saml assertion, send it to the idp and listen for their return post/get. Then I could redirect the client from their original login xaml style call.
Sharing my experience.
I have Spring-mvc + AngualrJs web application.
Webapp is based on token authentication, written a Filter that checks
authentication header.
Implemented SAML Authentication using spring-saml project.
Two main entity in SAM Authentication SP=ServiceProvider and
IDP=IdentityProvider
I have shared my metadata or SP metadata to IDP & IDP share his
metadata with me. for understanding communication protocol.
After successful login from IDP, we read response and generate my
application authentication cookies.
spring website for generating SP metadata :http://saml-federation.appspot.com/saml
Note: You can test SAML authentication implementation on public hosted IDP called as ssocircle
SSOCircle IDP metadata URL: ssocircle-metadata
I am not a security expert. We have prepared spring restfull web service with spring security.
Now I really have confusion about what is the best approach to secure our web service.
We are going to have SSL connection as well. Our web service will be use by our mobile application and web application.
I read about Oauth 1.0 and 2.0 protocol is very popular nowadays to authorize web services.
So can anyone guide me should I use Oauth mechanism because it is mostly use for accessing third party data, In our case it is not require but our client approaches to use OAuth2.0 or SSL with SHA hashing algorithm is just fine to secure web service?
If there are no third-party client applications which access your web service, OAuth 2.0 is not needed. Probably, HTTPS + Basic Authentication is enough.
If there is a possibility that you may feel like allowing third-party client applications to access your web service in the future, it is worth designing your Web APIs based on the OAuth 2.0 architecture from the beginning. In such a case, it is "Client Credentials Flow" that you will want to implement first among the four flows defined in RFC 6749 (OAuth 2.0). "Client Credentials Flow" does not require authorization by an end-user. That is, the flow cares about only client credentials (client ID and client secret). The initial implementation of your Client Credentials Flow would issue an access token only to your client application.
My one-sentence definition of OAuth 2.0 is as follows.
OAuth 2.0 is a framework where a user of a service can allow a
third-party application to access his/her data hosted in the service
without revealing his/her credentials (ID & password) to the
application.
Whether you should adopt OAuth 2.0 or not depends on whether third-party client applications access your web service or not.
I have an application runs on Java Spring 3. My application uses RESTful services and Spring Security for security. It has a user table and checks user credentials from it. I implemented web service capability to my application(one of customer's wanted web services instead of RESTful services). If possible I want same authentication mechanism and want to look up that database and allow just one user (for now-to admin) to communicate with my web service server.
Should I follow the same way as like my RESTful authentication or is there any authentication and security mechanism for Java Web Services at Spring (i.e. how to deal with logout, how to enable logout mechanism for a client-server web services communication)
PS: I use Apache-CXF.
Two potential ways:
Put a BasicAuthenticationFilter or DigestAuthenticationFilter in front of your CXF Servlet.
Use a WS-Security UsernamePasswordToken with CXF and write a CallbackHandler that a) creates a UsernamePasswordAuthenticationToken, b) calls authenticationManager.authenticate() and c) stores the authentication in the SecurityContextHolder.
Note that the above doesn't cover the concept of logout since login sessions are generally implemented with cookies and the above are stateless approaches. If you really need logout then you should consider using OAuth because you can implement logout by invalidating access tokens.
You could put a security token in the HTTP header you are sending to the REST which the REST decodes and verifies it's coming from an administrative location.