We use Keycloak to federate AD authentication/authorization for applications.
We have AD groups per application and control access by managing membership of these groups.
App1 - Admin, Basic, Manager
App2 - Admin, Operator, Support
We add user AD groups in to the token as custom claim, so that applications then know which user with which group has signed in.
Now for some realms, we need to control permissions for these groups from AD. For example: In AD we can define that Operator group has "p1, p2, p3..." permissions and instead of groups, we will add permissions in the token.
How can we do this? is it possible? what is the best practice?
Related
Scenario
We have an app that will be used by schools. Each school has an Azure AD instance that contains their staff and student users. These users have access to Office/Teams etc. through their school licenses. We also need to support parents having accounts and logging in.
For the parent accounts we would need to use something like B2C to allow them to create "local accounts" or sign up with their own Microsoft/Google/Facebook Accounts.
For student and staff accounts we would like to allow them to sign in with their AAD accounts.
My understanding is that this can be enabled with AADB2C by adding AAD as an identity provider within the B2C configuration. B2C also supports "IDP pass through" which allows you to get the access_token of the third party IDP being used.
My question is can this functionality (or indeed AADB2C at all) be used to get an access token that would allow you to access the signed in users MSGraph API (for whichever school it relates to)?
If not would that mean having to set up a B2C directory for the parent accounts and manage these completely separately from the AAD accounts that the school are managing for students and staff?
I've done a lot of reading and honestly, the more I read, the more confused I get xD
Totally can do that, heree a sample : https://github.com/azure-ad-b2c/samples/tree/master/policies/B2C-Token-Includes-AzureAD-BearerToken
Is there any Azure B2C end-user queryable endpoint that will allow that owner to identify which tenants they have authenticated to?
A dashboard for B2C users that is an aggregate of all tenants they have federated with? Is there some extension of the /common endpoint I could make an OAuth query to? (ideally including AAD B2B guest accounts)
https://account.live.com/Activity
https://account.activedirectory.windowsazure.com/r#/applications
myapps.microsoft.com
4/24/20 Edit:
I found this in the portal that implies a portal is available.
I'm looking for the API in which to programmatically add applications to it before a migration.
I need to have the applications already 'signed in' or linked to applications I own in the B2C directory (OIDC/SAML2 apps)
Your question is the equivalent of asking, "Can i find out if i registered at StackOverflow and Facebook with this/my email?". You cannot do this, AAD B2C is isolated tenancies representing a single organisations' identities. There is no equivalent of /common endpoint for AAD B2C. In AAD and AAD B2B accounts, there is a mapping created from the original account to identify which tenants they are in. This is to maintain a single identity across the Microsoft ecosystem.
In AAD B2C, this doesn't exist, goes back to my first sentence for 'why', they are separate applications, and inherently have no relationship, nor do the identities.
I am doing login from Azure AD.Client is SPA(angular using MSAL). If user is not Authenticated, it redirect to Microsoft Login Screen (using MSAL). On successful login, it return an access token.
My roles will be stored in a database. I need to add the roles of that user as part of claim in access token. I am not finding the way to do it.
I do not want to make another call from SPA to API to get the DB roles.
Please suggest some good approach.
Any links explaining the approach will also be very helpful.
I am still in design phase but not able to find the best approach.
In one microsoft site, i found that we can fetch the roles from DB but details were not there.
most of the places, it is written that we need to provide roles in Azure AD users menifest file.
In regular Azure AD, the "roles" claim is exclusively sourced from app role assignments for the signed-in user (or groups the user is a member of), to the app roles for the app the user is signing in to.
There's no feature currently in Azure AD which will connect to an arbitrary database, make a database query in the appropriate form, and include the results in the roles claim in the resulting ID Token.
I can think of three options to achieve your scenario:
After sign-in, call an API to retrieve the roles. Though you mention this is not desirable, it's probably the simplest approach, so it's worth listing. As a result of the user's sign-to you app, you app will usually obtain an access token to an API. If you set up your API to be secured with Azure AD (directly, or through Azure API Management), your SPA could simply get the necessary access token as part of sign-in, and at that point it's trivial to make a REST call to retrieve the role details for the user (and possibly other information useful to rendering your app).
Synchronize (or copy) your role information from your database to Azure AD. For each role, create an app role in the Azure AD app registration. For each user-role association, either create an app role assignment to directly assign the user (user -> app role), or assign a group to the app role and add the user to the group (user -> group -> app role. Keeping this in sync is probably not trivial, so if your scenario allow to move the role information to Azure AD app role assignment, you can forget the database entirely (making Azure AD the authoritative location). Of course, this might not work for your specific case.
Use Azure AD B2C and a custom sign-in policy. You could create an Azure AD B2C tenant, set up a custom sign-in policy to use your (regular) Azure AD tenant as the identity provider, and configure the policy to enhance the claims by calling a REST API to retrieve your roles. In this approach, you still need to have a REST API which can provide the role information, so rather than doing the setup and migrating your app, you may prefer simply calling the API from your SPA (option 1, in this list).
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.
After the Ad integration of the ektron site how to to go about preventing certain active directory users from logging in to the work area?
Quick and Simple answer:
Once you start enabling AD Authentication, it becomes all-or-nothing. You cannot mix user authentication modes.
CMS and Membership users can auth against Ektron.
CMS users can auth against AD and Membership can auth against Ektron.
CMS and Membership can auth against AD.
You cannot mix.
If everyone is a CMS users, but not everyone should be doing "stuff" in the Workarea, you need to start managing User Groups and set permissions to restrict or allow activity in Workarea based on those groups. First thing: Deny everything to the Everyone group. Then start allowing activity to other groups.
The Complex and Long explanation of user management in Ektron:
With AD Authentication and Integration options in Ektron, you have a couple ways to manage user authentication, and how users exist in the system.
Standard AD Authentication - When enabled through the Web.config with ek_ADEnabled, and then through the Workarea > Settings > Configuration > Active Directory > Setup > "Enable Active Directory Authentication", AD users that login to the system will be handled as CMS users. Explanation about this: Just checking the radio button here and leaving the checkboxes unchecked will force CMS authentication against AD. This does not auto-add authenticated users, update properties, or force them into groups. It simply tests their username and pass against an LDAP query. Using just this method, you manually add the users you want to authenticate for CMS/Workarea access into the Users. Any users that are not added, will not be authenticated. Any other users would then use a membership username and pass to authenticate on the site and will not use AD.
Active Directory Itegration - Using the above method, you can enable "Integration." This updates the users properties and information from Active Directory when they log in successfully. With "Authentication" the user information, aside from UserName, Domain, and password, is managed in Ektron whereas "Integration" forces the rest of the user properties to match their AD values. Just enabling "Integration" still forces the users to be added manually to Users and any AD users who do not exists in Users cannot authenticate. Instead, they would need a non-ad Ektron Membership account to login.
Auto Add Options - With "Integration" enabled, you can enable the auto-creation of users in Ektron. If a user logs in to Ektron and successfully authenticates against Active Directory, but does not exist in Ektron yet, the user account will be created in Ektron in the Everyone group and will be granted those permissions. This means that all Active Directory users on your domain can authenticate as CMS users and get access. Enabling the "Auto Add User to Group" takes this an additional step and checks their AD User Groups against the Ektron groups. If one of the Ektron groups matches an AD group they are in, they will be added to the group in Ektron.
AD Memberships - If you only want a couple users in your Active Directory tree to have CMS access, and want the rest of your users to log in to the site using Active Directory credentials, you can enable AD Memberships by setting the "ek_LDAPMembershipUser" flag to "true" in the Web.config. This will force all membership users to authenticate against AD like CMS users do, though they will not have CMS access. With this enabled, however, standard user, non-AD user, authentication will not work. The users will be forced to authenticate against AD. The integration and auto-add options will also apply to membership users in this case and you can use the Login control, or the API to set the AutoAddType or force a login to only allow membership users.
Now, obviously if you choose not to enable AD Authentication, all users are authenticated against Ektron only. No communication to AD controllers is made. If you do not enable "ek_LDAPMembershipUser" all membership users are still authenticated only against Ektron. AD/LDAP authentication does not apply to them.
There is no mix-mode authentication in the system, however. You can have AD enabled with CMS users against AD and Membership against Ektron. Or, you can have AD enabled with CMS users against AD and Membership against AD as well. You cannot have CMS users against Ektron and Membership against AD, nor can you have some users as CMS or Membership against AD and other users against Ektron only. I do believe complex options like these will be available in a future release, but for now, once you start enabling AD Authentication, it becomes an all-or-nothing affair depending on where you set it.
And a very important point that should be made about User Groups: You can enable AD Authentication and manually manage User Groups in Ektron. The groups do not need to match AD User Groups. This means you can define your own groups in Ektron, force users to authenticate against Active Directory, and you can apply permissions to the Ektron Groups, independent of AD Group permissions.
I hope this helps shed some light on the user system.
This may depend on what version of Ektron you're on, but I believe this is an issue with the later versions of Ektron where they added the login logic directly to cmslogin.aspx.cs rather than using the cms:Login server control.
A workaround that I know of requires manually editing the login page (cmslogin.aspx) to prevent users from being automatically added as CMS "authors" using EkEnumeration.AutoAddUserTypes.Author and instead be added as membership users only.
You can also create your own login page to customize the logic and remove the stock login page; whatever you do, backup the stock page first :)
You may be able to play around with this piece:
m_eAutoAddType = EkEnumeration.AutoAddUserTypes.Member; // I added this.
if (bAutoLogin)
{
UserInfo = m_refUserApi.autologInUser(strUsername, strDomain, Request.ServerVariables["SERVER_NAME"], m_eAutoAddType);
}
else
{
UserInfo = m_refUserApi.logInUser(strUsername, strPassword, Request.ServerVariables["SERVER_NAME"], strDomain, strProtocol, m_eAutoAddType);
}
If i recall correctly, one of the few user options still available in AD integration mode is the "lock user" checkbox on their profile.
AD integration can be set up to affect either CMS users or Membership users. CMS users have workarea access whereas Membership users do not. It sounds like you have the wrong option setup.
In a typical Intranet scenario, all your users with AD integration tend to be Membership users. This way they can create content on the site using the Community and Social features.
Your administrators will often have 2 accounts: their regular AD account and a CMS-only account that they can use to administer Ektron through the Workarea.