Is it possible to integrate Windows Azure Pack with Active Directory and have domain users authenticate Tenant Portal using Single-Sign On? Can anyone point to some good articles.
Note: I know WAP supports ADFS but I'm looking for plain AD support !!
The Windows Azure Pack Tenant Portal uses claims-based authentication. It delegates all authentication to a Security Token Service (STS) that must:
Support WS-Federation
Expose a Federation Metadata endpoint
Be capable of generating JSON Web Tokens (JWT) with at least ‘UPN’ and optionally ‘Groups’ claims
To use Active Directory credentials (NTLM/Kerberos authentication) you would need a STS that meets these requirements and can use Active Directory as an Identity Provider (or will federate to one that can.)
Examples include AD FS 3.0 (as you point out) and the STS that ships with WAP for use by the Management Portal. In theory, you could use the Management Portal STS for the Tenant Portal as well, but the documentation explicitly cautions against this, warning that doing so 'will cause tenant scenarios to break'.
See this article for a full explanation of this and links to more resources:
http://msdn.microsoft.com/en-us/library/dn479300.aspx
Related
Our organization uses Azure AD and not Microsoft AD DS .
Does OneLogin integrate with Azure active directory as a 'Directory' apart from the traditional on-prem AD DS. Is there any way to use Azure AD as a directory.
There is an Azure AD application in the applications section, can we use it to import users from Azure AD? Seems like it's an SSO app only and does not do user provisioning/syncing!
Out of desperation, I also tried the Azure AD Connect to sync to a dummy on-prem ADDS to Azure AD and then sync this dummy ADDS to OneLogin, but this seems like a very hackish way to do it and has it's own host of problems.
I'm not able to figure out how to contact support; there is no support email mentioned on the website anywhere.
Not similar to Connecting OneLogin to Azure Ad, as I am trying to add Azure Ad as a directory and the aforementioned question is about an error in federation configuration in Office 365 application of OneLogin.
Any help on this would be immensely appreciated! Thanks in advance!
After a conversation with OneLogin support, here's a few ways to achieve this paraphrased:
"We are not able to utilise Azure AD as a classic on-premise directory (such as we might use for AD synchronisation using the OneLogin Active Directory Connector) although customers who pay extra to Microsoft and have enabled LDAP are able to use our "LDAP via SSL" option although this does not allow for any customisation.
We do have plans to deliver some expanded directory offering but there is no release date for this and you can register a vote and add use-case notes for this request using our IDEAS channel. On US based systems you can use the IDEAS button available at the bottom right corner of the administration screen otherwise access https://onelogin.ideas.aha.io, select your tenant and then login. Then look at https://onelogin.ideas.aha.io/ideas/IDEAS-I-1488
If you can generate a CSV list of users in AD then you can import users using a CSV file into OneLogin - still a manual process but you may find this less complex than using the on-premise server - see https://onelogin.service-now.com/kb_view.do?sysparm_article=KB0010529
The "Azure AD application in the applications section" is for going in the other direction and is for using SAML 2.0 with OneLogin as an Identity Provider and is used for Microsoft Azure AD tenancies where there is no Office 365 involved but users need access to other apps installed in Azure AD.
The other mechanism being used is to have Azure AD as a Trusted IdP and then also enable Just-In-Time provisioning. This allows the Azure AD users to authenticate to Microsoft and then have a SAML assertion sent into OneLogin and dynamically create all the required fields that the classic directory synchronisation might have allowed (see https://onelogin.service-now.com/kb_view.do?sysparm_article=KB0011181)"
I decided to try Just-In-Time provisioning, will update if any blockers!
I must preface by stating that I am not an expert in Microsoft AD, Azure AD, and Office 365. I've read scores of Microsoft documentation, support and Stackoverflow posts and have not been able to find an answer to this specific question.
I have a web application that has an option for users "Sign in with Office365". This was implemented using Microsoft's ADAL library and the OAuth 2.0 authorization flow.
I have a customer who uses ADFS and Azure Active Directory together (Federated Identity in this document). They are federating their user's sign-ins with AD FS which delegates authentication to an on-premise server that validates user credentials which in turn allows their users to access Office365 and other cloud services.
Their on-premise AD syncs with Azure AD and does not sync passwords.
My question is two fold:
1) Will the standard implementation of OAuth 2.0 authorization flow work support this setup? Will Azure AD know to go to ADFS to do the authentication?
2) Is it possible to leverage Azure AD and the OAuth 2.0 authorization flow as an IDP proxy to ADFS?
1) Will the standard implementation of OAuth 2.0 authorization flow
work support this setup? Will Azure AD know to go to ADFS to do the
authentication?
Yes this works very well, as long as you have setup the federation with a verified custom domain using Azure AD Connect (Federated Identity in this document). I have live examples of it with a web application that uses OAuth 2.0 Authorization flow (without requiring anything special from web application code/configuration standpoint).
Flow is that you go to the Microsoft login page first > on selecting the work/school account and specifying user name > you get the ADFS login page > after entering credentials here, it continues just like a normal Azure AD account would.
2) Is it possible to leverage Azure AD and the OAuth 2.0 authorization
flow as an IDP proxy to ADFS?
In a way yes. Although it's not a regular Federation trust setup with certificates being exchanged, as you have to use AzureAD connect instead, like you mentioned in the link above (Federated Identity in this document).
We are developing an application in which we plan to use Okta as the ID provider. However, this application will be hosted in Azure and we would like to use the Azure ACS for Federation. However, off late we came to know that ACS is going be integrated with Azure AD (http://blogs.technet.com/b/ad/archive/2015/02/12/the-future-of-azure-acs-is-azure-active-directory.aspx). I am bit confused here.
I understand AD provides the directory services and will be used for authentication. In our case, this will be Okta. How can I use AD (as ACS is going to be integrated with AD) for this? I tried uploading a Ws-Federation metadata for a test application from Okta to Azure ACS (tried to create a new ID provider), however I couldn't succeed in doing that. Any help will be much appreciated.
I tried using Okta APIs, and it worked well. But, the ask is to use Azure to communicate with Okta.
You can set up Okta as the IDP to Azure since you plan to leverage Okta as the directory and as the IDP. The benefit here is that you can leverage other policies and features within Okta for authorization during login time (eg. mfa).
https://msdn.microsoft.com/en-us/library/azure/dn641269.aspx - This page provides a pretty detailed description on how to set this up. So effective, Azure is not "directly" communicating with Okta - but rather - integrating with Okta where Azure (and your app) is the SP and Okta is the IDP.
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.
I understand that WAAD is meant for internal organizational accounts. I understand the concepts behind ADFS and other "AD in the cloud" related topics. But is there really anything that is preventing WAAD to be used for public accounts?
I want to build a public facing web site using ASP.Net MVC. I will use WIF to implement claims authentication and plan to use ACS as a claims federation provider. I want to allow the end users to login using Social Network Accounts (out of the box with ACS). But I also want to allow users to register their own user name and passwords for my web site. Can I use WAAD for this part?
Of course I could build my own custom STS. Or I could use Thinktecture IdentityServer for this purpose. But there are some clear advantages of sticking with WAAD:
simplicity (to set up WAAD as a STS to ACS takes just few clicks)
performance, security, reliability guaranteed by Azure SLAs
Is there any disadvantage to this approach?
You certainly can use WAAD for creating user accounts. You, also of course, have to force users to use e-mail style logins.
There is however one (BIG in my opinion) disadvantage of WAAD against ThinkTecture's Identity Server: WAAD does not have a user registration / password management / password reset flow.
UPDATE (29.07.2014)
Today WAAD provides Self-service-password-reset as part of Premium Features. However still no self-service-user-registration. Frankly I do not expect to ever see self service user registration, as WAAD is targeting enterprises, and not your specific scenario.
To implement mentioned flow in WAAD, you have to developed your own MVC App from scratch, that uses the Graph API for all mentioned scenarios.
On the other side, you have Identity Server, which has thousands of downloads, which is developed by the Gurus of Claims based authentication and security. Identity server has very rich and easy to use extensible structure. While it also does not provide the user registration and password reset flows out of the box, it is already an MVC 4 application with very rich extensibility points.
Setting up an Identity server for run in Azure is also extremely easy. And setting up Identity Server as Identity provider in Azure ACS is just couple of clicks on the management portal.
You say that WAAD is SLA backed, highly available, etc. But your Identity Server deployment on a Cloud Service will be SLA backed too if use at least 2 instances of a Web Role.
If I have to chose whether to extend Identity Server to support user registration etc, or to create entirely new application from scratch that uses WAAD GRaph API for that feature - I would use Identity Server.
As of September this year the Azure B2C preview is there. This should satisfy the scenerio of self service user registration and different identity providers (Facebook, Google, Microsoft...). These are all serviced from AzureAD.
Azure AD b2c
There is als a complete MVC sample available
Azure AD b2c MVC Sample