I'm wondering if anybody can share some practical experience here:
I have a client making extensive use of the OKTA identity solution for single sign-on to various cloud/web applications (both internal and external) as well as extensive provisioning options (creating users in SaaS apps, adding them to groups etc.). They also use OKTA in combination with Radius to provide MfA for Linux users setting up VPN's and for shell login on Linux (dev-ops) servers. Their sign-in to O365 / D365 is at this stage also federated via OKTA, performing SSO into on premise Active Directory.
When they implemented OKTA 2 years ago Azure AD was not yet mature enough in this area but my feeling is that it since has become mature enough to replace OKTA. We want to make use of AAD Premium for SSO and provision, the Microsoft Company Portal and Azure App Proxy for reverse proxy if internal web applications. We also want to use the NPS plugin for AAD MfA for providing MfA during Radius login requests.
In other swords we will need to make use of just about every tool in the Azure AD box to meet the various requirements imposed due to migration from OKTA (current implementation has unfortunately become a "requirement").
Does anybody have experience with migration from OKTA to AAD?
Are their any experiences with extensive use of provisioning options for SaaS apps in AAD?
Any advice, tips, experiences are welcome and much appreciated.
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
It is straightforward to configure Azure App Service authentication for one of the following authentication sources: Azure AD (federation), Microsoft (local AD), Facebook (OAuth), Google (OAuth) or Twitter (OAuth). I have two questions:
Is is possible to allow more than one authentication sources from that list (hence with a Home Realm discovery)
Is it possible to add any arbitrary SAML 2.0 Identity Provider?
I don't see a way to do either one via the Portal, but perhaps are there other ways, such as via API?
Thanks!
Usually the most desirable option is as follows:
Your company UIs receive tokens issued only by Azure AD
Your company APIs receive tokens issued only by Azure AD
Users can authenticate multiple ways
Azure AD can federate to other identity providers
BEWARE OF COMPLEX SOLUTIONS
Any solution that returns multiple types of token to your UIs and APIs is usually bad. They will add a lot of complexity to your apps.
AZURE AD FEDERATION
The goal is for your Azure AD to manage complexity for your apps, and to return a consistent user id regardless of the login method.
There are definitely working SAML2P options - many companies use them for corporate sign in to Office etc
AZURE APP SERVICE
Not sure which category this fits into, but it's worth clarifying your goals before choosing the tech. SAML2P is a little complex but tends to be widely used in the corporate world.
We have a simple scenario but technologies(or implementation) have made things bit complex -
We have Sitecore as CMS for client's main web site and for business functionality we have Dynamics 365 Portal and we are using Azure AD B2C as identity provider for both.
We have heavily customised B2C custom policy to cater specific requirements.
We are using same custom policy in Sitecore and in Dynamics 365 Portals so sign in individually and works perfect without any issues.
With regards to SSO, we have kept the configuration as OOTB as you can find it here.
Only 1 or 2 user journeys are absolutely perfect as good as seamless journeys. In specific journeys we need user to be logged in both ends to make it work (we can force user to go to sign in page, but it is not required on all the pages).
In order to understand how real and proper SSO should work in Azure AD B2C, I have no idea or experience to relate this process to. so I am looking for guidance and help here.
I found very good information in this about how B2C works in terms of signin and providing tokens process but it bit old question and things have changed a lot since then specifically UI and some of the operations.
Use the following docs when configuring sessions management for a custom policy. Session Behavior section is where you define which SSO behavior. Specifically:
<SingleSignOn Scope="Application" />
If you want your users to get SSO between all applications, then define this value as "Tenant". There are several useful scenarios in creating separation between sessions - such as a company that has multiple brands that do not want to conflict each other. Or a separation of experiences.
Follow the exact format and location to be placed in your policy or you will not get the desired result.
Another concept that is important is the understanding the session provider:
SSO session management has two parts. The first deals with the user's interactions directly with Azure AD B2C and the other deals with the user's interactions with external parties such as Facebook. Azure AD B2C does not override or bypass SSO sessions that might be held by external parties. Rather the route through Azure AD B2C to get to the external party is “remembered”, avoiding the need to reprompt the user to select their social or enterprise identity provider. The ultimate SSO decision remains with the external party.
Session providers are used to define maintain what goes into generating the session when your policy is being executed (inside the Identity Experience Framework). If marked incorrectly, this could lead to undesirable results such as wrong claims being sent, additional MFA prompts, parts of your policy not being maintained when ran or just general errors.
This is for those who are interested in how we achieved this -
Sitecore also does offer OOTB Azure AD B2C configuration however the supplier of Sitecore delivery side decided not to use OOTB configuration approach and hence it caused lot of issues. From what I have read about Sitecore configuration for Azure AD B2C it does work smoothly with B2C with careful configuration.
Work Around: We had to rely on external triggers(e.g. cookie) which will indicate and trigger that a user has signed on either sides and accordingly the sign in process on both side kicks off.
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