I have a sample React SPA hosted on Azure that is using MSAL authentication. There would be different user permissions based on user role. Is there a way to change user roles (i.e. add or exclude user from AD group) using UI in my app. Is it done by calling graph API somehow? Maybe some example code you could show me?
The goal is to demo different app functionality for different user roles but dynamically change those roles in the app without going to Azure AD and manually assign roles to the user who is testing this app.
I need to be able to add logged in user into one of the groups on App registration from inside my react app and update interface when user role changes
There are 2 problems you may run into with this approach.
How does your app read the users roles. If it caches the user roles on login, then you need to logout and login again for the changes to take effect.
If the user is allowed to change their group membership in AD, then this opens a security issue.
For the purpose of your demo I would:
Have 2 browsers open. One with the user and one with Azure AD admin.
Show what the user can do
User log out
Change roles in AD
User log in
Show what the user can do with the new role
Related
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 creating a MVC core app that uses Azure Active Directory (AAD) as user storage.
I can create users manually in the AAD Users dashboard screen and invite external users without problems. They can also login into the app without issues.
Uninvited external users can also login to the app when agreeing with the consent screen which is what i want.My question however is how can i keep track of those users in AAD? They are not listed in the Users dashboard as external users nor are they logged in the 'Sign-ins' log screen.
Is there some option that i need to enable?
Since you want to use external users in your application, I would suggest that you use the Azure AD B2C solution: https://learn.microsoft.com/en-us/azure/active-directory-b2c/technical-overview
This will create a new B2C tenant from which you can track users that have integrated and logged in your application.
Check the consumer accounts section to see if this matched your needs:
Consumer accounts
With a consumer account, users can sign in to the applications that you've secured with Azure AD B2C. Users with consumer accounts can't, however, access Azure resources, for example the Azure portal.
My AD tenant has user consent disabled, i.e., all permissions added to AD app registration need an admin consent.
For an application using static permissions/scopes (v1.0 OAuth/OpenId endpoint), is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Microsoft docs say: "The app needs to know all of the resources it would ever access ahead of time. It was difficult to create apps that could access an arbitrary number of resources." Does it mean that for my scenario, all users need to wait for admin consent before they can access the app?
I receive the below error when a user tries logging in to the app using the Open ID Connect flow. For reference, my login URL is similar to https://login.microsoftonline.com/{tenant}/oauth2/authorize?response_type=id_token&client_id=b8ad6a99-cd23-40a6-a1b4-1184af990aa2&redirect_uri=https%3A%2F%2Flocalhost%2F&state=13ccfb84-cfd1-4cb0-bfe3-bb2c227e19f7&client-request-id=4d76947a-0000-48af-aeff-7bc2d5e40000&x-client-SKU=Js&x-client-Ver=1.0.17&nonce=ef1caa16-d3fe-4523-a9c9-000000000000
is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Yes, you can.
When the admin consent the API permission of an AD App(App registration), the permissions essentially will be given to the service principal(Enterprise application) in your AAD tenant. Actually if you use the AD App in your tenant, the permissions are essentially from the service principal.
You could refer to the screenshot below, there are four permissions, the two permission has been granted.
Navigate to the Overview, click the option Manage application in local directory.
Then in the Permissions, you will find the two permissions which have been consent.
When you add the new scopes, the app will keep working, but it will only be able to access the old scopes until the admin consents to the new scopes.
Thanks!
Alex Simons
I am building a native iOS application and want to use AADB2C as identity provider where users login, signup, reset their passwords etc.
I cannot figure out a way to let users signup with AADB2C (or regular AAD for that matter) without redirecting them to a (customizable, but still) microsoft website. To be perfectly clear: I want to let customers create user accounts on AAD from a native iOS form without redirecting them to a website, preferably via REST request. (Like here under "Create consumer user accounts": https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet)
Can you create users from an iOS app?
Yes, using the Graph API as per the article you showed. You can only create local accounts at this time though.
However you need to be very careful about how you do it given that currently, the ability to create users requires Directory.ReadWrite.All permission, which also allows all other sorts of operations. You should NOT put the client ID and client secret for an app with these permissions in your iOS app. Rather, you would need to create a backend service that exposes an API for your iOS app to call for user creation.
However, more importantly, what you WON'T be able to do is SIGN IN the users without a redirect (which is what the B2C sign up policy does). In order to do this from your own UI without redirects, you would need Azure AD B2C to support Resource Owner Password Credentials Flow so that you can, after creating the user, use this flow to sign them in and get a token.
Note: You would also need to disable Email Verification so that you can leverage the user account right after user creation. You can set this in the Sign-up policy or Sign-up/Sign-in policy via Page UI customization > Local account sign-up page > Email Address > Require Verification > No
Lastly, as an FYI, there's a feature in the works in Azure AD B2C: Customer Owned Domains, which, paired up with UI customization, would allow you to have sign-up/sign-in pages that you can look like your own and have a URL of your own, with no trace of Microsoft for your end users to see.
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.