Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
We're establishing an ADFS (2.0) that will be responsible for authenticating users for several, customer-facing systems. The authentication mechanism is out-sourced to an external partner, which offers access to several authentication providers.
We recently ran into the following scenario :
A user attempts to access customer-facing system A and is redirected to the ADFS for authentication.
The ADFS redirects the user to the authentication partner, where he authenticates succesfully.
The user is sent back to the ADFS with his authentication token.
The ADFS sends the user back to system A. He now has a session with it.
The user attempts to access System B, in which he is not yet
authenticated, and is sent to the ADFS.
This is where the ADFS strays from the behaviour we expected. Instead of recognizing the user, and transparently sending him back to System B with a valid authentication token, the ADFS sends him to our authentication partner for re-authentication.
This completely destroys the SSO functionality we wanted for customers using systems A and B, but we have not found a way to have the ADFS establish a user session and re-using that during access to the second system.
Has anyone solved this problem?
Can ADFS only deliver single sign-on when it's wholly responsible for authentication?
The ADFS is expected to behave this way, if your RP-s (System A and System B) have been configured to Force Authentication (ForceAuthn="true"). To resolve your issue, ensure that the freshness attribute is removed from the <wsFederation> element.
In classic ADFS, you set up the different authentication partners as claims providers with ADFS i.e. you federate the respective STS. This then provides the SSO functionality that you require.
It sounds like your problem is that there is only federation between ADFS and the external partner but not between ADFS and the authentication providers handled by the external partner.
Do you have access to the ADFS2 logs? In a Windows machine --> Event Viewer --> Applications and Services Logs --> AD FS 2.0 --> Admin.
Check also that A,B and ADFS2 are in the same circle of trust, and also the Assertion Consumer Services endpoints of the system B.
Hope it helps,
Luis
Related
I have an application integrated with Okta Secure web authentication (SWA) and MFA as additional layer of protection. Users can bypass this mechanism by accessing the URL directly in browser. Is there a way to restrict this from happening ?
This question ideally to be asked in product forum but I see a similar question with no proper solution.
I have to design an IAM solution for a NodeJS microservice using Auth0. Objective is to allow third party mobile application users to access this microservice.
I understand OAuth and OpenID connect solution and one simple solution is third party application accesses APIs as a client using client credentials workflow.
Solution I have to design is allowing users to login and authenticate using their Enterprise IdP connected to our Auth0 Server. So that we can implement authorization and access control at user level.
At the same time customer application needs to be kept agnostic of Auth0 service.
What I mean by it is client should not be required to add any logic in their application for accommodating our Auth0 domain like we have in first party React application. user once logged in to customer application should get access to our API also by using SSO capability. I have read some documents about configuring customer IdP with our Auth0 server acting as a SAML SP. Still I could not understand hows of it and will Auth0 create an OAuth access token in this scenario.
I realise this requires an app to intermediate between customer's mobile app and our API service. Still, I am not able to understand data flow and communication between various components.
Also, I am not sure it is a common situation or requirement? If it is is there any technical term for it? This not seem like a standard B2B scenario.
have to design an IAM solution .. , I am not able to understand data flow and communication between various components ..
Before answering, the answer will points the asked specific questions, may not fit al your needs. SO is not really intended for writing tutorials or searching the documentation. Implementing an IdP (effecively a security module), one needs to do his homework and learn the details.
Maybe using an ready / out of box solution could be interesting. Using an open source IAM such as KeyCloak, WSO2IS could be a quick start. Or cloud services such as AWS Cognito, IBM AppId, Azure AD, .. could be a feasible solution too
a client using client credentials workflow .. access toked received by our API should be for user logged in
The client credentials grant is intended to authenticate only applications. That's it.
To authenticate users, other grant type is needed. For the user authentication the most common option is the authorization code or the implicit grant. The implicit grant is has its weaknesses and is being replaced by the code grant with PKCE (just search it).
End requirement is users of 3rd-party application not required to login again while 3rd-party application fetches data from our API .. Configuring their IdP (most probably Active directory) and our Auth0 servers for the same is all I need to understand
I see most common two options in use:
1. federated SSO authentication
This is the most commonly used option. The external (3rd party) IdP is configured as a "trusted" federated IdP. You often see the scenario when you have a service provider allowing to login with other IdP, often social networks (FB, Google, ...)
The login flow is as follows:
The client authorizes with the provider's (yours) IdP (let's call it IdP1).
IdP1 now acts as as Service Provider with IdP2 (IdP of the partner) and asks for the authorization (redirects the user to the IdP2).
User is authenticated and authorized with IdP2. If the user is already authenticated, the IdP2 doesn't need to ask the user's credentials again, this is how SSO works on this level
IdP2 returns to IdP1 (acting as a service provider).
IdP1 reads the user information (using the id_token, userinfo service - assuming using the OAuth2/OIDC protocol all the time there are other protocols too) and builds its own the user-level token. It may or may not create a local user (it is called user provisioning).
IdP1 returns to the client and the client can request a user-level token.
Then the client can call the API services with the token trusted by the API provider.
2. Assertion Framework for OAuth Authorization Grants
This option is built on top of the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, it is an optional extension of the OAuth2 protocol. I call this a token swap service
Basically the token service could validate the access or ID token of a trusted (partner) IdP and issue its own token based on the provided user information.
As you see there are a lot of information and to build a secure solution you ned to make sure that all steps are properly secured (signature, expiration, issuer, validity, audience, subject domain, .. are validated). Disclaimer - as my job we implement IAM/IDM solutions and a lot can get wrong if shortcuts are taken. So you may really consider using an out of box and proven solution.
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
Our SAAS system is currently using standard Microsoft.AspNet.Identity.Owin libraries to authenticate users via Bearer tokens, as well social logins such as Facebook/Google/Twitter/etc.
Some of our users are asking for us to start allowing of authentication via ADFS.
I'm trying to understand how this can be done. Unfortunately, all of the blogs appear to dive right into the details without providing a good overview as to what's involved. Furthermore, most blogs talk about trusting a specific Active Directory, while we need to trust a whole number of possible customers' active directories - and do it dynamically. IE: customer registers for an account using custom username/password, then provides our SAAS application with some information about their AD. Afterwards, our SAAS application should trust authentication for users in that AD (just the auth part)
Can anyone provide information on what's involved?
TIA
Agree with #vibronet's points.
Another approach would be to add STS support to your SaaS application. This could be either WS-Fed or SAML. You have tagged the question with Azure so AAD could be an option.
You could then federate with any number of other STS's (like ADFS). Note as stated that each ADFS has to agree to add your metadata.
Another approach would be to use IDaaS (e.g. Auth0, Okta). These would do the Identity heavy lifting for you and would essentially provide the STS capability.
The question has 2 parts,
how to work with an ADFS instance and
how to deal with an arbitrary number of ADFS instances from different
owners.
The answer to 1) is to use the WS-Federation middleware, which can be added alongside the middlewares you are already using. However the initialization of that middleware requires knowledge of the location of the metadata document of the ADFS you want to target; furthermore, the ADFS administrator must provision your app explicitly or no tokens will be issued. Hence, the flow you are suggesting (temporary username/password and subsequent details exchange) might be tricky - but not impossible.
About 2) there isn't a way of wiring up an arbitrary number of different ADFS instances unless you modify the middleware setting pretty heavily. The actual answer is that the standard practice for dealing with that scenario is to rely on one intermediary ADFS (or equivalent) that can broker trust toward all others, while your app only needs to trust the intermediary ADFS.
This is a conceptual challenge that I'm trying to wrap my mind around. Let's say I have an SSO (single sign on) service and two separate web services that use it. Let's say that the SSO login happens via OAuth, just like Login with Facebook. (Correct me if I'm wrong that they're not just requesting an OAuth access token for the site in question.)
The question is then, how should the two web services expose their own APIs to third parties? Given that we've drunken the OAuth kool aid, it seems logical that the third parties should be considered OAuth consumers and they should request that the user approves an access token for them. Accepting that the question is, should the the web services handle all this OAuth stuff themselves, having the third parties register as OAuth consumers with them and only using the SSO to login the user? Or, should the web services hand all responsibility off to the SSO service? For signed requests, the web service would check the validity of the access token via the SSO's API and then process it as normal.
I see pluses and minuses to both approaches. On one hand, the first option places fewer demands on the SSO and each web service can handle the authorization for their APIs their own way. On the other hand, having the SSO handle things means that the third parties can get access tokens that are valid across all the services, just like how users can login across all of them.
This can enable a better user experience, as otherwise the third party might have to keep asking the user for authorization as it needs to use different web services of the system, despite the separation between the different web services being invisible to the user. Of course, then either the SSO needs to have some sort of shared permission rules or each web service will still need to enforce its own rules. Also, the SSO would probably have to take some sort of text or HTML from the web services to display when asking the user to authorize the third party service.
Any suggestions? Are there any existing, publicly documented systems that do this well? Am I just over-complicating the whole thing?