I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources.
Before I spend more hours on this I would like to confirm if my plan is even possible.
I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.
User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.
To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page).
Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form.
In other words
Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
Employee visits Azure app from internet -> Username+Password form
Customer visits Azure app from internet -> Username+Password form
While writing this question, two more came to mind:
1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?
2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?
Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.
Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.
Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:
http://www.microsoft.com/download/en/details.aspx?id=13789
More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.
And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs
One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.
If you look at...
HttpContext.Current.User.Identity
You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.
Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.
Related
I am new to Azure AD. I have to implement two websites which uses Azure Single Sign On feature to login. I have gone through few documents and blogs but it wasn't helpful enough. Could anyone suggest me a relevant document or approach for beginners.
This approach I am using:
I made a new tenant.
Made a app in app registration
Assigned the users through Enterprise Application changes
But now i have to add another website to webapp and then make sure if user logs in anyone of those then it should automatically get logged in other website as well.
When you have multiple applications in your organization, it's better to use Azure AD and you are on the right path.
To configure an application for SSO there are multiple ways. Based on your requirement you can choose any SSO protocol from below for authentication.
There are protocols like OpenID Connect, OAuth, SAML, password-based etc. to configure SSO.
As you have two websites, register two webapps in Azure AD and configure SSO
While registering the webapps, make sure to add redirect URI or Reply URLs of those two websites respectively.
Make sure both webapps are using same SSO protocol.
As mentioned in the comment by #Anand Sowmithiran, while the user is authenticating, the login flow will detect that user is already authenticated and will provide the token seamlessly.
For more in detail, please refer below links to get some idea:
Can I use Azure for SSO to multiple websites - Microsoft Q&A
single sign on - SSO with multiple azure web apps - Stack Overflow
I am facing a hopefully simple problem:
I need to create a wrapper app that contains a WebViewer control and should display a page in Azure portal.
I am developing the app in VS 2017 on a virtual machine which belongs to the domain 'DEV'. I would like to achieve that if a user from 'PROD' domain starts the app on their computer in the 'PROD' domain, they will be authenticated to AAD/Office 365 via SSO and can view the page in Azure (not a site in azurewebsites.net, but a site that needs you to be authenticated - i.e. portal.azure.com!).
I was not yet able to test the app on 'PROD' domain, but according to the answer below it would work, wouldn't it?
https://stackoverflow.com/a/9593258
If not can I go through the steps in the white paper mentioned and SSO the user manually (chapter 5.3, I assume)?
EDIT
Took me while, but here it is - I got SSO working, sort of...
In the end it seems that using a WebViewer control allows SSO but it still requires you to at least once enter your user name (user#tenant.com, for example) but you don't need a password. This might not be an optimal solution, nevertheless it is OK.
Thank you Wayne Yang for your support.
For your sceanrio, the user can SSO in PROD domain if the device has AAD joined.
But this should SSO to the joined AAD tenant. I also assume that you want to SSO to Azure portal with the ADFS. So, it also needs integrate ADFS with the AAD.
Why?
First, if your application try to sign in Azure portal via pop-up a broswer, and it needs SSO. AAD join can achieve this. If a device joined AAD, it will obtain a refresh token to your device. For windows 10 , IE and Edge can use the refresh token to SSO AAD endpoint.
Second, If you want to use ADFS, you must integrate ADFS with Azure AD. In this way, AAD authentication endpoint will redirect to your ADFS to approach SSO with your local domain.
Reference:
How to configure hybrid Azure Active Directory joined devices
Federate multiple instances of Azure AD with single instance of AD FS
Azure AD Connect and federation
Hope this helps!
iam currently researching how to implement Single Sign On for our WebService.
This is what i came up with so far.
If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.
Here is were my problem begins.
Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.
As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in.
(Its called : enabling automatic user provisioning in the azure management portal).
However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)
Can someone provide some insights on how to accomplish the following?
Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user.
So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.
(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)
Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)
"Bonus Question":
Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)
Please see my answer to a similar question here: asp.net azure active directory user profile data
However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.
HTHs,
I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality.
This is the documentation i found very usefull.
https://msdn.microsoft.com/en-us/library/hh974476.aspx
I'm customizing an ACS home realm discovery page and want to accommodate users who have either a "microsoft account" (aka LiveID/Passport) or a Office365/Azure Active Directory account.
In this situation, it's possible for the following workflow to happen (as far as I understand it)
User logs in using ACS custom page
User selects "Microsoft Account"
User types in their company / corporate ID
The HRD process at http://portal.microsoftonline.com redirects them to their ADFS server
Their ADFS server redirects them to their company.
Once sign-in passes (or fails) the login would cascade back to the ACS page.
What is the most efficient way (for the end user) to integrate Azure ACS, with Azure Active Directory / Office 365, with a custom HRD page that I create?
Or more plainly, is there a JSON web service that I can query to determine if a given domain or account exists within the "Microsoft Account/LiveID" world, and also check AzureAD for the same thing.
You cannot treat "microsoft accounts" (Windows Live ID / Outlook.com / hotmail / xbox /etc) the same as WAAD accounts when using ACS. When you set up your identity providers in ACS you will need to enable a Windows Live IDP and one IDP for each WAAD instance you are going to allow users to authenticate with. One thing that is not clear to me from your question is if you are needing for you users to be able to authenticate against a single WAAD tenant or from multiple. If one then you only need to configure one WAAD tenant in ACS. If you need to allow users to authenticate against multiple WAAD tenants then you will need to set up and IDP for each in ACS. For example if your web app is a SAAS application with users from companies "Contoso" and "Northwind" and you want them to be able to authenticate against their company's on-premise active directory then you will need two WAAD tenants setup. Each WAAD tenant will need to have federation configured with their given on-premise active directory. Each WAAD tenant in turn would need to be configured in ACS as an IDP. You could name those IDPs distinctly in ACS something like "Contoso WAAD" and "Northwind WAAD". Then in your custom implementation of the HRD page you can either just list all the IDPs and let the user choose, or if you want to be fancier you could parse the JSON results from the ACS endpoint that lists IDP and present them to the user (or just redirect them) based on some other selection they had made.
I am looking at Windows Azure ACS as an alternative to implementing my own username / password scheme in my app. This will be a publicly available website.
In addition to using SSO providers such as Google or Facebook, can I use Windows Azure ACS to support username/password authentication?
I see that it supports Active Directory as a provider. I am not sure this is the right thing as I have always thought of Active Directory as an "enterprise" provider.
Windows Azure ACS does not support username/password authentication in the form you need. Shahin outlined it in details.
Your options really are:
Windows Azure Active Directory (WAAD)
Identity Server (IdSVR)
While classic on-premises Active Directory deployed with a Domain Controller option is indeed quite enterprisy, WAAD is not exact copy of the same in the Cloud. I would actually recommend that you give a shot and try out. Using the WAAD Graph API you can fully automate user management in WAAD.
Your second option is based on IdSVR. This is full-featured Identity Server and Security Token Service. It is developed against the best practices in security and is quite easily extensible! While it does not provide out of the box support for user management (user registration, password reset, etc.) it is ASP.NET MVC 4 application. So you can very easily add this features yourself. There actually is an open enhancement planned for User Management API and UI.
Both WAAD and IdSVR integrate well with ACS, so you can provide seamless support for social identities along with own login.
Another service that is still in Beta/Preview is the SocialSTS project. It is kind of extension to Azure ACS and is designed to help you add more identity providers (such as LinkedIn, Twitter, GitHUB, Amazon Login, etc) to your Access Control Service.
You can authenticate directly with the ACS by using Service Identities, but they are not intended to be used for end-user authentication, as the page explains:
Service identities are not intended to be used as end-user credentials. In ACS, service identities are most commonly used in REST web service scenarios, over the OAuth WRAP protocol, where a client requests a SWT token directly from ACS to present to the web service.
I believe this is the only way to directly get a token from the ACS.