I have a use case where I have different AD/Ldap user stores that support both on premise and cloud. Certain applications need to use their credentials from their respective user stores. Something like the following:
AD (On Prem) -> Okta -> App 1
LDAP (Cloud) -> Okta -> App 2
Both should go through Okta but App 1 should only be linked to the AD when users are authenticated. I will use Delegated Authentication to make sure they use user store credentials. However, I am unsure how to make App 1 only available to AD and not the LDAP store.
You can assign all your users from AD to Okta group "AD Users" (if you don't have any other AD group, which has all AD users in it) and then inside your application sign on policy you can only allow this group to have access, the rest will be rejected
Related
I design a SaaS application that can be used by small companies with multiple users and big corporations using their own SSO.
Small companies need to be able to sign in, change and reset password, use 2FA.
Big corporations need to use their ADFS, Okta, etc. to authenticate.
How can I implement such a scenario in Azure?
OPTION 1
Create Azure B2C tenant for every big customer. Configure federation to client's identity provider. F.e. they will be redirected to b2clogin page and then to their ADFS login page.
Create one tenant for all small clients.
Ask Azure support to lift the limit for 20 B2C tenants.
OPTION 2
Ask clients to create Azure AD. Ask them to register our application there.
OPTION 3
Connect with clients' identity providers directly without Azure using OpenID Connect or other protocol.
Use-case – a SaaS product Northwind has many large and small clients. Large clients use SAML, Azure AD, Windows Active Directory. Small clients do not have their own identity provider, users can sign in by password or using Facebook or Google authentication.
Contoso User -> contoso.northwind.com -> redirect to sso.contoso.com -> redirect to contoso.northwind.com with SAML response
Fabrikam User -> fabrikam.northwind.com -> redirect to sso.fabrikam.com -> redirect to fabrikam.northwind.com with SAML response
Fourth Coffee User -> fourthcoffee.northwind.com -> enter email/password -> internal authentication
Fourth Coffee User -> fourthcoffee.northwind.com -> click Facebook button -> redirect to facebook.com -> redirect to fourthcoffee.northwind.com with access token
Internal User -> portal.northwind.com -> enter email/password -> enter OTP token -> internal authentication
There is no reason that you can't have one B2C with multiple federations including social e.g. Facebook.
This could be used by smaller customers as well.
You could handle the federation directly using Home Realm Discovery.
If you need to manage users e.g. licences, do that in a separate database and access via REST API.
My Azure Active Directory have 2 directories:
User1Directory
User2Directory
My app configured with User1Directory and I successfully logged in using User1Directory users, but I want login using User2Directory.
Okay so you have 2 Azure AD tenants (directories).
If you want to allow sign in from multiple tenants, you need to make your app multi-tenant.
Then you have a couple options for how you can handle authentication.
Your app will regardless have to check the issuer of tokens as changing an app to multi-tenant allows login with any tenant.
You probably want to check the issuer is one of those 2 tenants.
Your app could offer two login buttons, one which redirects to https://login.microsoftonline.com/tenant1-id/... and the other to https://login.microsoftonline.com/tenant2-id/....
This approach supports external guest users in those tenants as well.
The other approach is that you can instead always redirect users to authenticate with https://login.microsoftonline.com/organizations/....
This will allow the user to sign in with any Azure AD tenant.
It's simpler from your app's side but it does prevent external guest users in those tenants from signing in as the organizations endpoint (like the common endpoint) always logs the user in to their "home" tenant, making the issuer that home tenant.
I have included SSO (SAML) authorization in my existing application. But for me it was an unpleasant surprise to find that only 2 types of users can use the login through the providers I added (Okta, Azure AD):
Users who are located in the corporate directory of the provider (for example, I made an application on my account, there are no more
users. This means that any other user will not be able to use the
login form, because he is not a member of my tenant)
Third-party users of companies, whose administrators have added a
template of my application from the general list and connected their
users to it.
I expected other results, I need ANY user to be able to log in through these providers (regardless of whether he is in the corporate directory or has his own separate account that is not integrated into my application)
I thought about changing the SAML protocol to OIDC (OpenID Connect), but it seems to me that everything will work in the same way (at least Azure AD, because it seems there are no other options for working with it, except for corporate distribution)
Who had a similar experience, could you tell me what I should use among technologies and protocols so that ABSOLUTELY ANY user can log into my application through Okta / Azure AD / Google? Thanks!
Azure AD login fail screen
Okta login fail screen
You can use Azure AD OAuth2 flows and multitenant apps with MSA (personal account) support to allow any user from any domains and personal accounts to login into your application. Or you can switch to Azure AD B2C (which also relies on OAuth2) to connect different identity providers (Local Azure B2C, Azure AD, Facebook, Google, Amazon, Github, Linked in, Twitter, generics, etc) and allow all their users to login into your application.
I'm in a pickle, lacking the experiences that would provide me with guidance in my project and am seeking pointers from those for whom have Azure AD, SSO and Federation experience.
I am building an employee self service system and using Azure AD for identity management. I would like the user to be able to sign in using their employee ID # and password, not their email address; there should also be an option for the user to register for online access using their employee ID # and other personal information - their Azure Identity already having been established by humane resources.
The sign in flow would take the user to the Microsoft login page which would in turn detect that the user needs to sign in via a custom login page and redirect them there. Once they are signed in, my server would transmit their identity to Azure AD and grant them access based on the Azure Application permissions.
I'm simply really confused about how to start setting this up, if it's even possible. I'm aware of XSS but isn't Federation and SSO with SAML2 secure?
Do I need to use a federation application as a middle-man such as Ping Identity?
Thanks for any help!
Using e.g. Ping as an IDP generally won't help because Azure AD is already an IDP.
Microsoft Azure AD login pages can't be accessed by API and can't be customised to the extent you want.
And you can only sign-in with an email address because it's designed for domain-joined corporate customers.
You can do a lot of what you require with Azure AD B2C and custom policies. That will allow you to sign-in with a user name (= employee id) and you can create workflows.
You could then federate Azure AD and Azure AD B2C.
Your other option is to use an IDP that does allow authentication via an API e.g. Auth0.
Then you could have a custom login page that authenticates as appropriate.
Using Ping ID and other similar products is the fastest way to utilize SSO.
I want to do some automated tests of a web app (web api) in Azure that is secured with AAD. The customer is using on-premises AD to synch users and groups to AAD and is using ADFS to authenticate the users. This is enough, I believe, to stop me from using UserPasswordCredential to programmatically sign in a test user. So I have asked the customer to create me some cloud-only users that will be used in the automated tests. But we can’t add these users to the AAD groups, presumably because they are synched back to on-premises AD.
The web app is designed to check if its users are in a particular AAD group, but my test users can’t be in that group, so we may have to modify the app to check for multiple groups instead, and put the cloud-only tests users into a cloud-only group, so that we can add the cloud-only group to the list of groups allowed to call the web app.
Is this the best approach, or am I missing a better solution?
UsernamePasswordCredential is meant to work with ADFS via federated tenant, as long as the proper endpoint is enabled in ADFS.