SSO - Microsoft Entra ID

please note that in mid 2023 microsoft renamed azure active directory to entra id microsoft entra id (previously azure active directory) provides a saml idp capability that allows you to use your office 365, or on premise active directory as an authentication mechanism for servicely you will need a servicely administration account, and an azure account with administrative privileges example walkthrough below is a walkthrough video showing the entire process preparing servicely in servicely, you will need to create an ‘identity provider’ search for ‘identity provider in the menu, and select 'new’ enter a name for the provider, a unique ‘client identifier’ (will auto generate), and select ‘create’ consider naming the record to be unique to your servicely environment for example, for production, if you call the record "entra id", then for a dev environment, you may want to call it "entra id dev" this is because the generated "client identifier" needs to be unique in servicely and to keep copies of non production identity provider records, it is advisable to copy them over to the production environment, albeit in a deactivated state preparing entra id log into entra id and navigate to ‘azure active directory’ → ‘enterprise applications’ select ‘+ new application’ select ‘non gallery application’ provide the ‘name’ for the application, and press the ‘add’ button select ‘single sign on’ or ‘set up single sign on’ select ‘saml’ for the single sign on select ‘edit’ on the ‘basic saml configuration’ form example if client identifier is on servicely’s authentication identity provider is “azure ad” https //\<instancename> servicely ai/idp callback?client name=azure ad next we need to configure the identifier, reply url, and logout url these are in the format setting value identifier https //{instance name} servicely ai/idp callback?client name={client identifier} reply url https //{instance name} servicely ai/idp callback?client name={client identifier} logout url https //{instance name} servicely ai/idp callback?logoutendpoint=true\&client name={client identifier} enter the values and select ‘save’ below shows an example if the servicely instance name is staging demo next, add the users of groups you want to have access from the application select ‘users and groups’ and update accordingly finally, return to the ‘single sign on’ screen, and download the ‘federation metadata xml’ file optional configuration token timeout by default, azure ad configures the applications with a 90 day token expiry (before the user needs to re authenticate) to change this, you need to configure a ‘conditional access policy’ with the appropriate rules finish servicely configuration return to the servicely ‘identifier provider’ entry you created above, and paste the content of the ‘federation metadata xml’ you downloaded from azure ad into the ‘idp metadata xml’ field, and save the record servicely will reformat the document, and generate the appropriate ‘sp metadata xml’ entry depending on your machine and software used to get the xml, may dependent if it copy pastes correctly if possible, we typically suggest using a code editor that sees it as xml or other software that treats it as xml this is due to software such as word and wordpad can add extra “hidden” values in the background important configuration options idp user attribute and sp user field the ‘idp user attribute’ field allows you to customise which saml property from azure ad is used to lookup the associated user record in servicely this field defaults to the ‘id’ attribute, which is the users email by default in azure ad the ‘sp user field’ defines the servicely user field that will be used to lookup the associated user record by default, this would be ‘email’ for the default azure ad configuration maximum authentication lifetime this field allows you to configure the lifetime of a saml authorization token this should be carefully matched to the configuration of the azure ad application by default, azure ad supports a rolling 90 day window before requiring the user to login again, and will continue issuing the same token to servicely for that period this means the value for this field should, by default, be set to ‘7776000’ (90 days in seconds) forcing re authentication in entra id in some configurations, the lifetime of the entra id saml session is a rolling session, in which case the above ‘maximum authentication lifetime’ will cause the servicely application to reject the token returned by entra id if the session becomes older that the ‘maximum authentication lifetime’ value to fix this, a ‘conditional access’ rule needs to be configured in the entra id enterprise application to create the policy enterprise application → security → conditional access → new policy set the values as below guest user logons your guest users can login into servicely as long as their user records are also synchronized over to servicely however, you may need to update the entra id user attribute mapping for the username attribute, from userprincipalname to originaluserprincipalname example below microsoft's reference document https //learn microsoft com/en us/entra/identity/app provisioning/how provisioning works#b2b guest users https //learn microsoft com/en us/entra/identity/app provisioning/how provisioning works#b2b guest users