I am setting up a STS using WIF which will support active and passive federation.
There will be multiple services which use the STS as relying parties.
I want to know how the scenario works and is implemented where one service (eg. RelyingParty1) is the client of another service (eg. RelyingParty2) where the client of RelyingParty1 (a physical person/user) authenticates via STS/Idp username and login and RelyingParty1 wants to use RelyingParty2.
Does RP2 communicate with the STS at all, or is a valid token passed from RP1 to RP2? Is there specific configuration needed for this?
If RP2 can/does communicate with STS to verify token/authenticate (SSO is not a requirement so checking each time might be desirable) how does the STS know to use the physical user of RP1 as the IClaimsIdentity/IClaimsPrincipal and not the user that RP1 is running as?
A Relying Party (RP) is the entity that expects a Security Token from an STS (an issuer of tokens). A user of the RP is called a "subject" (or user) and it is not an RP.
The RP knows that the token is valid because it is digitally signed by the STS it trusts, so (generally) no communication between the RP and the STS is required.
You can chain STSs:
RP -> STS1 -> STS2 -> User
In this scenario, STS1 is also a "Relying Party" because it is relying on STS2 to get a valid token. In this scenario STS1 may also be called a "Federation Provider".
I would suggest reading the first chapter of this guide: http://msdn.microsoft.com/en-us/library/ff423674.aspx
It will give you an introduction of terminology and architecture.
Related
I have a legacy system that has an existing login mechanism - assume it is a custom method. We have another set of services that require an oauth2 access token and use keycloak for generating and verifying the tokens. After a user logs in we no longer have access to their password hence I can not use the password grant to get them an access token to our oauth based system. What are the recommended approaches to generate this access token. What I have looked into so far:
impersonation (token exchange)
custom keycloak userstore SPI that validates user with blank password
I guess using a client credential flow to generate a token that tries to match the users roles and attributes.
It seems to be a use case that is not well supported by oauth2?
It seems to be a use case that is not well supported by oauth2?
Your use-case seems to match those defined in the OAuth 2.0 Token Exchange specification
One common use case for an STS (as alluded to in the previous section)
is to allow a resource server A to make calls to a backend service C
on behalf of the requesting user B.
For this approach, you will need to configure in the appropriate Keycloak realm your legacy system as Identity Provider. So that you create a trust-relationship between the legacy system and Keycloak. Afterwards, you can exchange the token coming from the legacy system (resulting from the user authentication) for a token of the aforementioned realm. Depending upon your setup you might need protocol mappers that map the legacy system roles to the roles in the Keycloak realm. All of this is assuming that your legacy system is to a certain extend Oauth2 compliant.
Otherwise, another approach is for your legacy system, to call a confidential client on Keycloak and pass along some claims (e.g., the user roles). This is assuming that your legacy system can securely store the client secret. All of this, of course, depends upon the concrete characteristics of your setup.
I have created a Single Page Application with Angular and authentication/authorisation is managed by Azure AD. I have used MSAL.js to initiate the implicit flow.
Everything is working fine, but now my client wants to use her own identity provider (IDP) so that users have a single point of entry for all apps (including mine). This IDP is not mainstream, it is built in-house by the client;
I want to keep using Azure AD to manage authorisations (groups, roles...). I also want my application and its dedicated backend API to be registered in Azure AD, not in the third-party IDP.
Azure AD should remain responsible for providing the Access Token to the SPA in order to call the API.
Somehow, I should redirect the user to the third-party IDP login form and upon successful login it will redirect to my SPA, which should then associate the tokenID with an AzureAD account and retrieve the Access Token (I suppose I will have to create an account in Azure AD for users identified in the third-party provider)
However I'm having a hard time figuring out how to achieve this and if it is at all possible ?
What would be the recommended approach for this scenario ? Can I still use MSAL.js or do I have to rely on something else ?
ARCHITECTURE
Your goals are completely correct and you should not need to change a single line of code to integrate a new IDP - so you can continue to use MSAL.js.
PREREQUISITES
In order to integrate their own IDP into your system you need to insist on certain prerequisites:
The client needs to provide a Standards Compliant Identity Provider
Typically the IDP needs to communicate with your Authorization Server (Azure AD) via either Open Id Connect messages or SAML2P messages
A home grown IDP may not meet these prerequisites in which case you need to explain to the client that they need to get standards compliant.
HOW FEDERATION WORKS
Your UI will redirect to your AS
The AS will redirect to the IDP, when given a trigger
The user will authenticate in the IDP
The IDP will post a token to your AS to identify the user
The AS will issue another token to your UI
Note that there is no coding involved here - there is only standards based integration between vendor systems.
WHAT THE CLIENT WILL GIVE YOU
Client details are often supplied by giving you their metadata document, and these details are then configured in Azure AD as a trust entry:
The entity id of the IDP
The token signing public key for IDP tokens, so that your AS can validate them
A URL to redirect to
WHAT YOU WILL GIVE THE CLIENT
A similar trust entry will need to be configured in the client IDP so that it trusts requests and issues tokens - though no certificate is usually needed here:
The entity id of the AS
A URL to post tokens to
TRIGGERING THE REDIRECT FROM THE AS TO THE IDP
One option is to forward the entity id to the authorization server in Open Id Connect redirects. Often an 'idp' query parameter is used, something like this:
Client accesses your app with a bookmarked URL:
https://app.mycompany.com?idp=urn:client.com
You add an extra parameter to the Open Id connect redirect to tell it where authentication should happen:
https://login.mycompany.com/authorize?client_id=XX&idp=urn:client.com
AZURE AD SPECIFICS
Once you understand the high level process there is some technical stuff to configure the connection and you'll need to consult vendor documentation, such as this Microsoft Azure B2B article.
PRACTICE
If you haven't done this before then you need to invest some time to get a connection working and then document the process.
You can use Windows Server and ADFS to simulate a client connection, then integrate it as a SAML2P connection. There is a learning curve though, and you'll need infrastructure such as ADFS certificates.
I'm trying to implement authentication/authorization in my solution. I have a bunch of backend services(including identity service) under API Gateway, "backend for frontend" service, and SPA (React + Redux). I have read about OAuth2.0/OpenIdConnect, and I can't understand, why I shouldn't use Resource owner password flow?
A client ( my backend for frontend server ) is absolutely trusted, I can simply send users login/password to the server, then it forwards them to Identity server, receives the access token && refresh token and stores refresh token in memory(session, Redis, etc), and send the access token to SPA, which stores it in local storage. If SPA will send a request with the expired access token, the server will request a new one using refresh token and forwards the request to API Gateway with the new access token.
I think in my case a flows with redirects can provide worth user experience, and are too complicated.
What have I misunderstood? What potholes I'll hit if I'll implement authentication/authorization as I described above?
OAuth 2.0 specification's introduction section gives one key information on the problem it tries to solve. I have highlighted a section below,
In the traditional client-server authentication model, the client
requests an access-restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with
the third party
As a summary what OAuth wants to provide is an authorization layer which removes the requirement of exposing end user credentials to a third party. To achieve this it presents several flows (ex:- Authorization code flow, Implicit flow etc.) to obtain tokens which are good enough to access protected resources.
But not all clients may able to adopt those flows. And this is the reason OAuth spec introduce ROPF. This is highlighted from following extraction,
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application.The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
According to your explanation, you have a trust relationship with client. And your flow seems to be work fine. But from my end I see following issues.
Trust
The trust is between end user and the client application. When you release and use this as a product, will your end users trust your client and share their credentials.? For example, if your identity server is Azure AD, will end users share Azure credentials with your client.?
Trust may be not an issue if you are using a single identity server and it will be the only one you will ever use. Which brings us the next problem,
Support for multiple identity servers
One advantage you get with OAuth 2 and OpenID Connect is the ability to use multiple identity servers. For example, you may move between Azure AD, Identityserver or other identity servers which of customer's choice (ex:- they already use on internally and they want your app to use it). Now if your application wants to consume such identity servers, end users will have to share credentials with your client. Sometimes, these identity servers may not even support ROPF flow. And yet again TRUST become an issue.!
A solution ?
Well I see one good flow you can use. You have one front end server and a back-end server. I believe your client is the combination of both. If that's the case you could try to adopt authorization code flow. It's true your front end is a SPA. But you have a backend you can utilise to obtain tokens. Only challenge is to connect front end SPA with back end for token response (pass access token to SPA and store other tokens in back-end). With that approach, you avoid above mentioned issues.
I would like to provide some standarized SSO mechanism in my application (some different clients, growing number of services in the backend). I am wondering if OIDC/OAuth 2 is the right tool for it.
In all examples I have seen, end user is the Resource Owner and it grants permissions (or not) to some external apps by redidericting to a page asking for permissions.
My use case is different, I want to use OAuth inside my system (for apis, web pages etc.): resource owner is i.e. some service with database (plus administrator who have access to it), end user tries to get some resources from the system. User cannot grant anything, he can be granted. I think it's the most classic scenario, which can be named Single-Sign-On. Is there any standard flow for this in OAuth 2 (or preferably OpenId Connect)? Is it achievable? Or am I looking at a wrong tool?
OIDC/OAuth can be used for both consumer as well as enterprise scenario's. The consent steps of OAuth are useful in consumer oriented scenario's. When dealing with enterprise scenario's like yours, there's no point in asking consent since it is implicit, at least for the enterprise's apps. That is certainly covered by OAuth/OIDC: the Authorization Server is not required to ask for consent and can (typically) be configured to skip that step for particular Clients. So: using OpenID Connect without consent would be suitable.
For your usecase you can use combination of OpenID Connect and OAuth Client_Creds flow. For example suppose you have a HRMS application which needs to get the employee data to show to the employee from some DB.
Register HRMS with OPenID Provider
Register HRMS as Client to OAuth Server (OpenID Server and OAuth Server can be same)
When User comes to HRMS application:
a. Check for Id_token cookie, if not present then redirect to IDP
b. IDP authenticates and if successful redirects back to SP with ID token
c. If token is valid then SP sets the token as cookie in the browser using another redirect to itself but to the home page
Now All processing will be server side:
a. HRMS app hits the IDP to get the User Data
b. If successful then it hits the OAuth Server to get the access_token
c. if successful then it uses the access_token to talk to DB Service and
get the data
SP=Service Provider, IDP = Identity Provider
Actual flow can be a little different based on security considerations.
Hope this makes it helps.
I'ld like to implement SSO using SAML 2.0 in my web applications. I have seen spring-security-saml example [https://github.com/spring-projects/spring-security-saml.git]. There are a couple of things I wanted to know after I went through this sample:
Do I have to redirect all the user-registratons to the registration page of IDP as in this sample ? If not, how does the IDP know the credentials of the user?
Do the IDPs' like ssocircle (used in this sample) allow us to use customized attributes and change password kind of scenarios ?
What is the best IDP to use to implement saml sso in my application ?
Thanx in advance.
Q. Do I have to redirect all the user-registratons to the registration page of IDP as in this sample?
In SAML parlance, an application can be an identity provider (IDP) or a service provider (SP). An IDP authenticates users, which means that user identities and credentials are maintained by the IDP. An SP provides one or more service to the user.
From your question, it seems that you want to delegate the task of authenticating users of your application to an external party (the IDP). Therefore, your application will be the SP.
With that established, you will have to redirect all users to the IDP for authentication. The IDP's authentication page may have a link to the registration page, if required.
Q. How does the IDP know the credentials of the user?
The user must be registered with the IDP (after all, the purpose of the IDP is to authoritatively authenticate a user's identity, which it cannot do if the user is not registered with it). Users can be self-registered or registered by an administrator, such as, a Microsoft Active Directory Domain Administrator.
Q. What if I need to register the user in my system as well since I need to assign them roles specific to my system?
You can create your own implementation of org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler wherein you can check the authenticated user on successful single sign-on and register them with your application. Supply an instance of your implementation class as the redirect handler to the SAML entry point.
Do note that you will not have access to the user's password since that is stored by the IDP.
Q. Do the IDP's like SSOCircle allow us to use customized attributes?
SSOCircle is mostly a testing service for SSO (single sign-on). Although SAML supports custom attributes, SSOCircle only supports FirstName, LastName and EmailAddress (as of February 2016). Therefore no, you cannot use other custom attributes with SSOCircle.
Actual IDP's like Okta, OneLogin or Microsoft ADFS do support custom attributes. You must check their respective documentation for configuring and exchanging custom attributes between the IDP and the SP.
Q. Do the IDP's like SSOCircle support change-password kind of scenarios?
I am not sure about SSOCircle but an actual IDP will be a system that already has user identity management capabilities. Since password change is a common functionality for an identity management system, this should be supported with an actual IDP. However, you should consult the documentation for the actual IDP you use to make sure.
Q. What is the best IDP to use for my SAML application?
An IDP is not a product or a specification, making this question somewhat invalid. It is simply a type of actor in the SAML universe. If your users are part of a Microsoft Windows Active Directory forest, you can use Active Directory Federation Services (ADFS) to exchange SAML messages between Active Directory and your (SP) application(s).
If you want to support multiple Active Directory forests, or if you do not know in advance where your users will be, you can use delegation-based services like Okta or OneLogin, which allow your application to take incoming assertions from the delegation service.