I have web application which is my relying party and I want to implement SSO for more than one client.
Add STS reference will add claim info in my web application but can i add multiple STS reference for multiple clients/claim providers?
The "correct" way to do this is to add other clients as Claims Providers in ADFS.
Then when you connect, ADFS will show a "Home Realm Discovery" screen which will allow the user to select the provider of choice.
Each relying party should only ever know about 1 STS. However if you want to support multiple Logins/STS's you can do this by making your first STS - an STS but also a Relying party. So when your relying party redirects back to the first STS, the first STS then delegates the responsibility for creating the token back to the second STS. The second STS issues a token to the first STS. The first STS takes this token and sets its claimsprincipal with it, then it isssues a token using this identity to the original Relying party.
Like so:
Related
How can I add authentication when using the Logic App action?
The Microsoft docs around using the action for nesting only detail making the call; nothing on adding any authentication.
I know I can use the "raw" HTTP action, but this goes HTTP, whereas the Logic App action goes direct to the workflow, i.e. no HTTP. And this means you can NOT enable the Access Control setting to limit calls to only other logic apps when run in an ISE.
We also want to move away from using the SAS key in the logic app URL, over to using the Azure AD OAuth authorisation policies for management of the authorisation
If you want to move away from using the SAS key in the logic app URL, over to using the Azure AD OAuth authorisation policies for management of the authorisation, the best way to do it would be through API Management.
At this time (2020-10-28), there is no way to add OAuth authentication to the Logic App action
You have to use the HTTP action in the logic app, which allows you to add an Authentication parameter
You can then select the Authentication Type from ...
None
Basic
Client Certificate
Active Directory OAuth (i.e. Service Principal)
Raw
Managed Identity (i.e. either User or System Assigned Managed Identity)
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 need to create User Management Service which will be central point to authorize AD users for multiple applications. Applications can be both intranet or Internet, internal or external.
What I figured out it will be something like Identity Server. But due to some requirements we doesn't want Identity server but custom STS (Security Token Service).
- We need to take input from 3rd parties credentials
- validate in our Active Directory
- generate & send SAML token to authenticated users.
I have looked into :
https://katanaproject.codeplex.com
http://www.c-sharpcorner.com/UploadFile/scottlysle/windows-identity-foundation-and-single-sign-on-sso/
http://garymcallisteronline.blogspot.in/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
https://msdn.microsoft.com/en-us/library/ms972971.aspx#singlesignon_topic9
https://coding.abel.nu/2014/08/kentor-authservices-saml2-owin-middleware-released/
But I am still confused how 3rd party will understand that SAML or need what to interpret that shared identity info.
3rd party app can be on any language other than .Net too
they don't need to make change into their code/implementation.
Please suggest.
This is conceptual/architectural question so please don't advise to add code & then to offer help.
We currently have a typical forms authentication setup in our organisation; with a login page located at something like account/login. We want to retain this but also want to start securing some of our APIs with OAUTH2 ; essentially we are the provider.
From reading a fair bit about the subject Microsoft's OWIN OAUTH implementation moving forward isn't supported (e.g. vNext) and doesnt support all the flows with OAUTH2. Thinktecture's identityserver3 seems to be the "standard" and most complete solution there is currently.
I cant seem to find an example of using identityserver3 with an existing app that requires forms authentication.
We would be looking at using it in two different ways; one using the implicit flow using javascript where we allow a third party site to call our API once the user has logged in to us (using the forms auth) and the user has allowed the client to access specific scopes.
The other use case, I think , would use the authorisation code flow ; the client would be requesting this so it can auto login (much like a login with Facebook - but login with X company) or be already logged in if logged in our site.
Any help with these scenarios would be most appreciated.
I think it will not be possible to switch your app to OAuth without changing your existing login.
I would suggest you use Identity server with custom user store(https://identityserver.github.io/Documentation/docsv2/advanced/userService.html) to use your current user database. That way your existing login accounts will be used by the identity server.
You can then secure your APIs with OAuth using the Identity server. You might need to change the way your current app call the APIs too. This means users of the current app will be redirected to identity server's login page. You can brand your login pages using custom views to make it appear similar to the curent login page (https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html)
Currently I have 2 relying parties setup in the same ADFS server; one for my web api and one setup for MVC application. When I get the token for authenticating in MVC app I capture this token to send it to my web api for authentication as well. This token does not work for the web api.
If I specifically make a new call for that relying party(web api) it will work so i think that it is setup correctly in ADFS...
Is there a configuration issue in ADFS not not allow the same token to work for both?
Is this even possible?
Is this the wrong architecture in ADFS?
Should I use one relying party for both apps?
You can use Identity Delegation which helps in scenarios like this where an app calls a service instead of a user.
This similar question has some good resources:
Pass ADFS Token to a Service