We have set up our admin to be accessed using SSO via our companies Azure Active Directory.
That was the easy part.
What I am trying to achieve now is to add custom roles.
We want to alter our approval/publishing workflow. We are aiming to have the following steps:
Editor makes change; then a head of department approves content; then a member of a comliance team approves changes; then a publisher pubslihes the changes
I can't do this with just WebEditors and WebAdmins. And no documentation I have found works to achieve having these roles available in the CMS.
Tried adding role types programmatically, adding them through appsettings, but only have the standard web editor and web admin available.
If I go into the assign access screen for content, no added roles are present.
If I try and assign a role to a publishing step, no added roles are present.
I can't use the built-in roles management, because roles are created through Azure AD, but I cannot find a way for these roles to be usable in Optimizely V12.
For simplicity, I am simply trying to add the "Compliance" role, but no documented processes I have found seem to work.
Any help greatly appreciated.
For adding new roles, you can't do through appsettings. If I understand correctly, your roles are configured and coming from Azure AD. If that's the case, it's quite easy by just adding additional roles through azure ad and assign to to users.
In Azure AD, it's called "App Roles", you can find within your Azure AD app, then assign to users. Once they all configured, you can log out and log in your user again, all news roles will be synchronised into your CMS that you can use to customize your approval workflow.
I hope above helps.
Thanks for the reply.
I know the roles and user assignments are managed via Azure AD.
The problem is, if I add a role to Azure AD, for example "Compliance", I then want to be able to set access rights within the CMS for that role.
However, the CMS has no idea of roles inside Azure AD. So I need to somehow update the CMS so that it is aware of the new role, so that it can be assigned.
This has sort of worked for me a a small degree already, as we added a role to Azure AD (SEOAdmin), which I then added to the appsettings which allowed users assigned to that role to log in, and access a aprticular package.
However, even that role is not usable in any way with regards to Access Right assignment or assiging to approval sequences.
This must be possible somehow.
That's not what I experienced in the past. Once you added app roles in azure ad, if you code has been setup correctly , on your next login to CMS, azure ad roles should be synchronised to your cms ( you can verify them from cms database, look for tables in your db, you should be able to see a few tables named with sync and one of that is to store the roles synchronised back from Azure AD)
Please check this doc for your openid setup
and pay attention to the followings
"If you have EPiServer.CMS.UI.AspNetIdentityinstalled, make sure you are not calling services.AddCmsAspNetIdentity()in startup.cs. Otherwise, the user interface may not look for synchronized users when setting access rights."
and the following line must be invoked
Ah, maybe I missed something in that - It's useful to know that it should be synced form AD!
I'll go and investigate all that now. Thank you!
Thank you Vincent! - I did not have EPiServer.CMS.UI.AspNetIdentity installed, but was missing the await synchronizingUserService.SynchronizeAsync(claimsIdentity); call - doh!
Though that partially addresses things.
I can now see the added role to assign to an workflow approval step, but still not available to assigning access rights to content?
Amazing what a few days away from code can do for the brain!
Vincent, yur suggestion fixed the entirety of my issue. What I thught was the remainig problem was me just being stupid.
Thanks a ton
Thanks for the update and mark this question as resolved. Glad to hear you managed to resolve all your issues. Enjoy the rest of journey for your Opti CMS development.
Where can I customize this to the level of allowing specific screens or certain parts of the admin console to be available to some editors. Or conversely, maybe removing publishing rights from Admins.