We're currently using IdentityServer 4 with some modifications to be multi-tenant according to the OpenID Connect (OIDC) specification which has a acr_values query parameter.
So we pass in &acr_values=tenant:acme as query parameter in the URL when redirecting to the identity provider.
We want to migrate from IdentityServer 4 to Azure Active Directory (AAD). Is it possible to configure one AAD instance to be multi-tenant? Using the acr_values query parameter with the tenant key?
As an IdP, Azure AD is indeed multi-tenant, however instead of targeting a tenant you target a multi-tenant app.
Regarding IdentityServer4 acr_values param, it's meant to be used to bypass IdP selection thus it's not needed since you only need to pass the proper client_id param and build the Azure AD protocol specific (OIDC/OAuth2) endpoint using a multi-tenant id such as organizations or common. E.g. https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• You cannot have one Azure AD instance for multiple tenants since tenants are subscription based and every tenant can be specified as an independent directory having its own custom domain name with verified DNS records as the authoritative start of the authority for all the user identities created in it. Thus, it acts as a central authentication and authorization directory for all the identities and applications created in it.
As a result, as of now, only applications in an Azure AD tenant can be configured as multi-tenant, i.e., multiple tenants share the same physical instance of the app. Although tenants share physical resources (such as VMs or storage), each tenant gets its own logical instance of the app wherein application data is shared amongst the users within a tenant, but not with other tenants.
• Thus, since you are migrating from IdentityServer4 to Azure AD, you must configure Azure AD as a federation IDP and configure your IdentityServer4 in that way such that when a user tries to login to a SaaS app through a user identity that is created in IdentityServer4, then he is redirected to the Azure AD for authentication purposes and accordingly token is issued and once again, he is redirected to IdentityServer4 for further application based purpose.
To configure an application as a multi-tenant application, kindly refer to the below snapshots for reference: -
Also, to add ‘IdentityServer4’ as an IDP to Azure AD, kindly ensure to add it as an ‘App Registration’ in your new Azure AD tenant as stated below and ensure to add the same details in your SaaS app that is configured for authentication with ‘IdentityServer4’: -
• Register your application with your new Azure Active Directory tenant by clicking on App Registrations --> Register an application --> Name: IdentityServer4 --> Accounts in any organizational directory
• Then, in the Redirect URI field, enter the ‘callback/redirect URI’ path configured in IdentityServer4 for Azure AD authentication which will be like ‘http://localhost:5000/signin-aad’ which you can find it in the ‘IdentityServer4’ project in the ‘Startup’ class in the ‘ConfigureServices’ method.
• Also, ensure to configure the token and redirect URI as below: -
This will ensure that ‘Azure AD’ is configured as an external identity provider in your application as below by configuring the correct ‘Application ID, Tenant ID, etc. correctly. In this way, you can surely configure ‘IdentityServer4’ as an IDP in Azure AD: -
services.AddAuthentication()
.AddOpenIdConnect("aad", "Azure AD", options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.SignOutScheme = IdentityServerConstants.SignoutScheme;
options.Authority = "https://login.windows.net/<Directory (tenant) ID>";
options.ClientId = "<Your Application (client) ID>";
options.ResponseType = OpenIdConnectResponseType.IdToken;
options.CallbackPath = "/signin-aad";
options.SignedOutCallbackPath = "/signout-callback-aad";
options.RemoteSignOutPath = "/signout-aad";
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name",
RoleClaimType = "role"
};
});
Please find the below link for more detailed clarification on this: -
https://www.ashleyhollis.com/how-to-configure-azure-active-directory-with-identityserver4
https://identityserver4.readthedocs.io/en/latest/endpoints/authorize.html
if all your tenants are with azure ad, then yes, you can have a multi-tenant app registration to login your users from multiple azure ad tenants.
Related
We have integrated keycloak with Azure Active Directory and integrated it with a few applications.
We have a few applications that are directly integrated with Azure Active Directory. Is there an approach I can follow to make a person logged in to one application to be signed in all the other applications irrespective of the authentication provider used (keycloak or Azure AD)?
Normally I'll be logged into all applications integrated with keycloak if I signin into one application integrated with keycloak and vice-versa with Azure AD.
Your requirement can be fulfilled with the app service feature by leveraging the token store and authorization behavior of the configured authentication providers for the apps configured. But only tokens received from keycloak can be forwarded to Azure AD for authentication purposes and further sign in respectively to all apps registered with Azure AD. The reverse is not possible as keycloak doesn’t has the ability to forward the sign in token request received for the application configured back to Azure AD for authorization.
You will have to enter the REST API code for signing in and out of a session accordingly by incorporating the below likewise code in your environment.
Log in with the Microsoft Identity Platform
Log in with Facebook
Log in with Google
Log in with Twitter
Log in with Apple
Please find the below documentation for an approach on forwarding the authentication tokens from Keycloak to Azure AD for access authorization: -
https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-customize-sign-in-out
Thanking you,
In Azure AD i have a multi-tenant Enterprise Application and App registration that are accessed through SAML2. I receive a limited set of users attributes, including tenant-id, email, first name, last name. But the organisation that the user belongs to, has defined extension attributes in their on-premise AD that i want to consume in my application. Also i would like to receive the jobTitle and Department in the application. The organisation says they have set up synchonisation of the attributes from their on-premise AD to Azure.
I have added the attributes i want under the Enterprise Application -> Single sign-on -> User Attributes and Claims -> Additional claims. But i am obviously still missing some configuration somewhere because they do not appear in the SAML2 token.
Which API permissions do i need to grant my application to pass these attributes through to the SAML2 token? Do i need to add something else to map these attributes?
when you set up a multitenant app, when your client's users / tenant signs in, it actually creates an "enterprise application" (service principal) in their tenant for your app. https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#understand-user-and-admin-consent
As per that, your client would have to go into the SSO (saml) setup screens for your app in their own tenant and customize the claims that they will emit to your application. It doesn't matter if you add the attribute claims to your own SSO setup. thats for your tenant, not theirs.
It turns out that the Single Sign On properties are not visible in the Service Principal, because the proper tags are not set in the Application registration.
After using Microsoft Graph Explorer to see the properties of a working Service Principal with SSO properties, i noticed that it had a tag set that was absent in the Service Principal without SSO properties in the portal.
In the Application Registration manifest i set:
"signInAudience": "AzureADMultipleOrgs",
"tags": [
"WindowsAzureActiveDirectoryCustomSingleSignOnApplication",
"webApp",
"notApiConsumer"
],
Then recreated the service principal in a guest tenant using an adminconsent link (https://login.microsoftonline.com/[guest tenant domain]/v2.0/adminconsent?client_id=[app registration id]...) the portal displayed the Single Sign On settings in the guest tenant.
The Azure portal seems to display SSO properties for Service Principals associated with Application registrations that have the WindowsAzureActiveDirectoryCustomSingleSignOnApplication tag.
To summarise:
Set the WindowsAzureActiveDirectoryCustomSingleSignOnApplication tag in the Application registration manifest.
Create a Service Principal in the Owning Tenant if you haven't done that already.
Use an adminconsent url to create a Service Principal in the Guest tenant.
Have the Guest Tenant Administrator fill in the single sign on properties to add the required attributes.
The attributes are returned to the application in the SAML2 token
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.
Lets say i have an WEB API that i have developed and the web API is already protected by Azure AD using App registrations.
Now the Web API has some roles like Admin User and Manager.
I want to store these roles in Azure AD too and get an accesses token for Azure so in the JWT claim of the accesses token the role is present.
Any pointers if this is possible at all ?
You could add an appRole into your Azure AD app and assign users and groups to roles.
Then the users in the group will have the claim like below:
{
"roles": ["{the role you customized}"]
}
After that, the role will be included in the access token. And you can implement your authorization logic based on the roles of the user.
I am using Aure AD B2C to connect a .Net core application with Azure AD Enterprise application for authentication using SAML protocol. I am using custom policies to enable SAML.
I have used custom policies starter pack given in Microsoft Docs, and authentication is working properly with given name, surname, name, IDP as claims and I want so additional claims that my application is using.
I need DOB and MemberID as claims for my application and there was no option to add custom claims to the active directory where my enterprise application is.
I have another IDP setup in Okta and luckily I could add custom claims like DOB and MemberID to user profile in Okta but still I am unable to get those claims after authentication.
This is an Azure AD question.
The problem is that DoB etc. is not part of the schema.
If you are using Azure AD Connect and these attributes are in AD, you can use directory extensions to synch them up.
You can synch them up to extensionAttributes that are in the SAML drop-down.
Then add them as outputs in B2C.
If not, you can add extension attributes to Azure AD and use a custom policy REST API that calls Graph API (either directly or via Azure function) to get them.
Also refer this.