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.
Related
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
We have a website that has its own register/login logic. The user table, passwords...
As a business requirement, we need to integrate a 3rd party website, seamlessly to our users. So when a logged-in user clicks on the 3rd party's link he should be logged in straight away and has passed user details.
The 3rd party website supports single sign-on, and ideally, we would like to use Azure AD B2C to implement SSO.
Is it possible to keep Azure AD as an alternative place of login? So we still register a user via our website, use our login, but when a user comes to the other website he logins via Azure AD. Basically, this would imply pinging Azure AD via Rest API whenever we have a new user and passing his details there, but also somehow asking Azure AD to do the login verification with us using a REST API on our side
Is this achievable, or there is a better way of implementing this?
Thanks
There is a way you can follow I have design it as well in the below picture. From this way it can be achievable
Step 1: Store the new user in data base that is signup in website1.
Step 2: Export the user list in CSV format.
Step 3: Upload the CSV file to storage account and the WebJob will be reading it to create users into the B2C directory.
Step 4 : if any new user comes for login in 3rd party website it will redirect to website 1 for register and if existing user comes it will prompt for Azure ad B2C authentication.
Please follow this document to implement the above scenario:
https://blog.kloud.com.au/2018/10/30/bulk-import-users-into-azure-ad-b2c-tenant-with-custom-attributes/
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.