I am working on an ASP.Net MVC application which will handle two types of users
External Users (Need to authenticate using Azure B2C with username as login instead of email as login)
Internal Users (which already exist in Corporate Azure AD)
What is the right way of implementing it?
One option is to run two separate instances of the application configured against each IDP. Keep each type of user stick to one app instance.
I tried to register AD and AD B2C in one app by registering two OpenIdConnect services but having problems when the user tries to access a resource without first logging into the application. Without knowing the type of the user I cannot specify AuthenticationSchema in the Authorize tag.
I am sure people have done this before so if you someone who knows how to do it, then please guide me..
Related
I want my application to be able to use an external user pool from my customers Azure AD, instead of them having to maually create every user in my application, when they already have them in Azure AD.
Initially, I though of using only OIDC for this as I can just create the user in my application upon the first login. But OIDC does not allow me to logout and deactivate the user in my application when they are deleted in Azure AD. This is an important requirement for my application.
To solve this, I think I could combine OIDC and SCIM:
Azure AD provisions the users to my application through SCIM endpoints. When deactivated, Azure notifies my application through the SCIM endpoints and I can delete their session and deactivate them in my application.
Login is handled with OIDC. When I have a valid OIDC token I create a session in my app. This way I don't have to manage passwords or multi factor authentication in my app.
Does it make sense to use SCIM and OIDC together?
Yes, it makes sense to use SCIM and OIDC together in the way that you describe.
It also has other advantages to "pre-provision" with SCIM: for example, when users want to address accounts other users that have not logged in yet. Adding such a user to a group would not work with "just-in-time account provisioning" since the account would not exist (yet).
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 have a consumer facing application (call it consumer.com) whose user identities is managed via. Azure AD B2C. This consumer.com app has admin screens which is accessed by the internal staff whose identity is managed by Azure AD. To enable SSO experience for the internal staff the organizations Azure AD is registered as Custom Identity provider in B2C tenant. This allows the internal staff to use the corporate Azure AD credentials to login to the consumer.com application by clicking on the appropriate 'External identities' button. In this flow if the internal user has already authenticated to Office365 then clicking on the 'External identities' button will automatically authenticate user. I was wondering if the experience can be improved by cutting short the need for internal user to click on the button, perhaps the user session that exist in the browser can be used to bring in this experience. How to achieve this?
I am also looking for a solution where user will click on a link (Consumer app button) within one of Office365 apps which would then redirect to consumer.com application, of course the expectation here is to directly authenticate without needing to go through B2c login page. If this can be achieved, what information should the url link contain?
Use the domain hint parameter:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin#redirect-sign-in-to-a-social-provider
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'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.