It is browser based or is it IdP based?
I am looking their official document, I could not find any details about session management. Is there anyone aware or session in SAML?
Technical Document: https://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf
Executive Document: http://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf
There is no "session management" in SAML, per se. Sessions are the responsibilities of the Identity Provider (IdP) and Service Provider (SP) individually. There are some key value pairs that can guide session creation on both sides (such as SessionNotOnOrAfter or NotOnOrAfter), but it's very rare to see them in use in that manner.
Most commonly, you will find an SP has a control available in their admin panel that allows the IdP's business unit using the SaaS provider to set something like an Idle Timeout and a Max Timeout based on their business requirements. On the IdP side, they'll manage it based on their own internal security requirements as well.
Related
My application is deployed in IIS which has plugins to connect to websphere where my application servers are spinned up. Websphere connects to LDAP for user auth. I have a requirement to have ONLY one user session allowed through websphere. If same user identity tries to login again on the same or other device or anywhere there should be some setting / configuration in websphere should prohibit user to make second session. Any direction on this matter will be helpful.
If you are using standard WAS security with form based login, you could take a look into this Redbook WebSphere Application Server V7.0 Security Guide. In the chapter "8.8 Customizing the login process" it shows filter that you could use for customizing login process. More detailed approach is also shown here https://www.ibm.com/docs/en/was-nd/8.5.5?topic=login-developing-servlet-filters-form-processing
In very high level:
you need db with table where you keep your current logins and login times (to provide some timeouting in case one doesnt log off properly)
in filter you check if given user has active concurrent login and return error page instead or pass through to the app.
This is very high level and you need to design it correctly to not lock out your users. E.g. user accidentally closing his browser would result with having to wait for the timeout before being able to log in again.
Another approach could be to logout any existing sessions, and log in just new user, but that approach requires you to have distributed session invalidation, which is also not an easy design.
So in short, I'd think twice if it is really required feature before implementing it, as it adds a lot of complexity to your applicaion ;-)
we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
While prototyping out an API & SDK, I've run into this question with several plausible solutions. I'm looking for help with some of the high level architecture. In short, it is guaranteed that some consuming applications of the API are going to want to configure their own authentication providers.
Options that I've been munching on:
Keep resource server and authorization coupled but figure out some way to delegate authentication in one of the authentication providers in my auth manager to the client application.
This sounds promising until I realized that in the particular use case, it's actually necessary that even my providing application not know the user's credentials.
Separate the resource server and make each consuming application responsible for providing an authorization server, and set those endpoints as part of the configuration when registering the consuming app with the resource provider.
This feels like an uncomfortable inversion of what is often desired when using authorization_code grant types. It also would require any "default" authorization providers to be implemented by each consuming application.
Some kind of delegating authorization server that falls back to a default if a client hasn't provided endpoints for their own authorization server.
This would probably be a good solution, but I'm not sure how to do it the "spring-security-oauth2" way or if I'd have to implement a bunch of my own stuff.
Create a default auth server, and optionally allow consuming applications to point to whichever auth server they want.
This seems viable approach in that it offers lots of customization. My concern is, how do I enforce some kind of registry with the resource server? If the auth server is the server that approves consuming applications, but I don't want to let any consuming application implement its own auth server, just some of them. Otherwise non-trusted clients could end up approving themselves!?
In case this influences any guidance, my resource provider will need a fully inflated OAuth2Authentication object (which contains user details and client details).
This image mostly explains what I'm talking about, except I want multiple authorization servers and want to leave it to the consuming application to decide which authorization server to point at. How could I check on the resource-server side of things that the authorization server proxying the requests is an approved authorization server?
ADDENDUM:
I took a look at the existing implementation that's being used for this custom authentication case and I guess we're just reading a token off their session that gets set by their own login service and building their user each time off of that. This sort of customization is a problem in that we're removing customizations from the provider side of things in favor of handling that in the consuming applications. So, I'm looking for solutions so consuming apps can define their own authentication means, to the point of even providing users that the providing application doesn't persist (which leads me to think it may need to be an entire auth server).
That being said, this seems like a potentially unsustainable inverted model (IMHO, the provider should be the maintainer of users and authorization, not the consuming apps). So, I'll probably recommend a more business oriented change.
I believe I have finally come up with a secure and maintainable way of solving this.
Let consuming applications optionally register an authentication callback with the authorization server.
Require incoming authorization requests from that application to the authorization server on behalf of a user to include a token, that token should be stored by the consuming application as a means of referencing whichever user is actively causing the API call.
When an authorization code request is received by the authorization server from an application that has registered one of these callbacks, then POST to that application's registered authentication callback and include the token that was provided by the consuming application in the request.
The consuming application should take the token that was POSTed to it's registered authentication callback and look up the corresponding user, and return a response containing the full user object on whose behalf the providing application should operate (or some kind of error code if the token is invalid).
The authorization server should then generate an authorization code and return to the callback uri submitted with the authorization code request. This means we're back on track according to step 4 in the diagram in the original question. The remaining steps can be carried out as-is.
There is a remaining question of how this might be implemented to take advantage of as much of the spring-security-oauth2 framework as possible while still achieving this extension.
starting a proof of concept for this model it appears not to be possible to configure the membership provider per request to the respective clients database. It appears that the web application instantiates the membership providers on application start and doesn't allow modification to this during subsequent requests.
I have tried using reflection and modifying the connection string in the Application_BeginRequest (in the global.aspx) but it appears that the membership provider is designed and implemented to only initialise once per application rather than per request.
This implies for the separate database approach, the default asp.net membership provider wont work with the single application/multiple database (multitenant seperate database) model.
what authentication/authorization model do people use in this architecture? do they use a custom implementation of the Microsoft membership providers or do they use a different package or library?
Cheers
Tim
In the case of a multi-tenant application development scenario, the best preferred is a SSO or to go with a custom profile management system.
In order for you to enable tenant based authentication using the databases, you can have a connection string manager that identifies your tenant based on some of the criteria like the company code or the URL and then use the user login data from that database for that tenant's users.
The usage will be like you identify / infer the tenant code from the login credentials and then choose the database that is available for that tenant and then authenticate the user against this database. Hence the tenants can have their own databases for their user's authentication.
This is feasible and can also comply with the regulatory requirements that may be for different tenants based on their geography.
I need to create a login page with a password reset workflow that includes sending a link to the user's email to the page to set their new password. I was thinking of using a Custom membership provider however, our system uses a back-end identity management system that all creation, validation and updates go through. All the examples I see for creating custom membership providers use a direct db connection. This will not work for me. So, I was wondering if it is advised, or even possible, to create a membership provider that does through a services back-end?
Sure, you can use services for your data access. You'll probably have to execute them synchronously, though.
Do you have the source and/or libraries for your identity management system? If so, you could access it directly in your provider, cutting out the service layer.