I'm using the Spring Security SAML extension for my SP. After a user is authenticated from the IDP, the SP uses some sort of method to allow subsequent calls to not have to be reauthenticated with the IDP. How is this done in the Spring Security SAML extension?
A related question:
Authenticating mobile users against SAML IDP
In the accepted answer from the above related question, the SP should create a token and pass it back to the client for future requests. I'm not seeing anything like this when watching the flow in Chrome's Network Tool. What should I be looking for?
Update 1: I'm coming to the conclusion that Spring SAML doesn't pass anything back to a browser in the form of a token. It must be keeping track of the user on the server side. Can I get confirmation on this? Is it possible to generate a token to pass back to the client in the case of a REST call?
Spring SAML is relaying on Spring Security for handling of user's authentication state. By default user state is stored in SecurityContext and Authentication objects which are put into user's HTTP Session (identified by secure cookie typically JSESSIONID which is passed to the browser). You'll be able to find all details related to this in the Spring Security documentation.
In case your user is calling REST APIs from browser where she authenticated, and the API is deployed together with the Spring Security application, the call will be providing same cookies as you would get for normal server calls and they will be authenticated using the same mechanism without need for any tokens.
In case you want to perform calls to a 3rd party REST API where you have not established a session or authenticated using other means, one way to secure such scenario is e.g. issue and use OAuth 2.0 Bearer tokens.
After the user is authenticated from the IDP, the IDP sends back a SAML assertion to the SP. The Spring Security SAML extension validates this assertion.
If the validation is successful, Spring Security establishes a user session, which is generally persisted through the cookie mechanism.
In the case of a REST service, your suggestion is basically what is done on OAuth-enabled REST services. The client sends an authorization token with each request.
Related
I'm looking to leverage the spring authorization server (https://github.com/spring-projects/spring-authorization-server).
I need to federate authorization requests to backing IDPs based on a set of rules. Is there some documentation or suggested entry points to where this could be implemented?
Rules could include:
By domain of the user name (first.last#some-domain.com)
By relying party client id
IDP hint query parameter as part of authorization request
EDITS BELOW - providing more detail and context to the problem:
Many applications will interact solely with the Spring authorization server via OIDC to authenticate users. Some users may have their credentials managed by a separate authorization server, e.g., google or facebook. In these cases, I would like to federate the authentication via OIDC to the specific identity provider.
Example Workflow:
Application --oidc--> Spring Authorization Server --oidc-> Google
There could be many ways that we could determine:
If we need to federate authentication
Which IDP to federate authentication to
We will support authorization code grant for user-driven OAuth flows. So every authentication request will start with a call to the authorize endpoint.
For example:
http://auth-server:9000/oauth2/authorize?response_type=code&client_id=messaging-client&scope=......
After this request, I'd like to configure the Spring Authorization Server to make the determination of where to federate the authentication if required.
potential options:
Have the user enter their username, then federate to an associated IDP
Look at a query parameter hint. For example: /oauth2/authorize?client_id=messaging-client&idp=google
Please let me know if I can clarify anymore.
See the Federated Identity sample.
While I don't have an example of all of the possible ways you could detect which 3rd party IDP to direct the flow to, this branch does have one example: Look at a query parameter hint. See the FederatedIdentityAuthenticationEntryPoint for an example of how to do this.
The idea is that once the /oauth2/authorize endpoint is requested via the browser, an unauthenticated user will be asked to authenticate, which triggers the AuthenticationEntryPoint. This is where we would probably want to detect the hint, or take any other action to initiate the appropriate flow or login page. Since the client_id is also usually available in that request, you could have multiple ways of responding to this request depending on your needs.
It's best to have a fallback though, so that the server responds in the "default way" when any of these mechanisms cannot proceed for whatever reason, so the implementation delegates to LoginUrlAuthenticationEntryPoint and redirects to a login page. This also happens to allow you to combine form login with federated login!
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
I`m new to OAuth 2.0 and am trying to develop a application using a third party OAuth provider with Authorization Code grant flow as ny Authorization Server and Spring Security.
This provider gives me two endpoints /authorize and /token and those two, after the user authorizes its access, will return a access token.
So far, I have secured the "/" endpoint, so the application redirect the user to the authorization page and then, in the callback endpoint, store the token so it can be validated by a filter in each request.
But, as the application is mainly a set of REST API's, we want to be able to test it using Postman, with that said, on Postman, I am getting the token by setting the Authorization as OAuth 2.0 and requesting the token directly from the third party endpoints but, as Postman have its own callback URI, my application doesn`t store the token generated.
So, my two questions on this are:
Using /callback endpoint to store the token and validating it before each request by a filter is the common way of doing it?
To use Postman, should I create an endpoint for storing the token generated outside the application context or should I create an Authorization Server of my own as an additional layer on top of this third party AS?
Since your application is a set of REST API's, you need to make it as a Resource Server (in terms of OAuth2).
Resource Server doesn't perform authentication itself, it only validates a token from Authorization header (Resource Server in a nutshell).
You can find an example in Spring Security samples: oauth2resourceserver
I eventually come to the conclusion that I was using Postman wrong the whole time.
So, by the end, we got the Token saved on the database when the user logs in and, then, return it to the caller, whether it is the Front-end application, or Postman itself.
Then, in every call to the API's, the caller should include the token as Authorization on the header and a Filter on Spring will check the token against the Database.
I have a use case where a web application needs to let users authenticate in two different ways but using the same user data store (aka IDP) via SAML.
User's browser is redirected to IDP and redirected back with SAML assertion (aka WebSSO Profile).
User makes request to SP providing their credentials via Basic Authentication. SP would then need to send the user's credentials to the IDP and the IDP would provide an assertion all through a back channel (server to server).
I'm using Spring Security SAML extension. The sample application in Spring SAML contains both basic authentication with username and password and SAML-based authentication but the Basic Auth portion uses local accounts defined in the securityContext.xml file. I need to use the user accounts on the IDP. Is this possible? If so, how do I configure Spring SAML?
There is no standard SAML WebSSO mechanism which would allow SP to request assertion for a specific user by providing her credentials. You might want to look into WS-Trust standard which covers such use-cases using its Request security token methods (RST/RSTR calls). Another quite standardized way to do this is Client Credentials grant of OAuth 2.0. Both are out of scope for Spring SAML, but can be combined with it.
I have a rest API made with Grails, I can use spring security via Ajax auth, and store the jsessionid cookie in the client, but when i login with 'j_spring_security_facebook_json?access_token=' it doesn´t create the jsessionid cookie... and i can´t store the session in the client.
Does exist any solution for this problem? thanks.
As you're using an external client (mobile app), in most cases you have to use something different for authenticating your requests. Not a cookie. Usually it's OAuth2 or just a custom signature based on a shared key.
j_spring_security_facebook_json auth is supposed to be used as an exchange point, where server can pass a key/token for mobile client that have valid fb token. Then this token could be used for authentication of following requests.
See "How to extend JSON response" at http://splix.github.io/grails-spring-security-facebook/guide/3%20Usage.html#3.5%20Json%20Authentication