lee mcdermott Posted October 6, 2020 Share Posted October 6, 2020 Hi, We are trying to setup SSO with AZURE. We have it working by adding individual users to the Hornbill Application Group in Azure. https://docs.microsoft.com/en-gb/azure/active-directory/saas-apps/hornbill-tutorial However we need a way to add all users to this group to allow both portal users(self service) and IT staff the ability to access Hornbill. Does anyone know how to do this? We tried creating a group to allow anyone with our domain name email address but this didn't work? We cannot add users individually as there are too many. thanks lee Link to comment Share on other sites More sharing options...
Hornbill Staff DR Posted October 6, 2020 Share Posted October 6, 2020 Hi Lee,  thanks for your post. Are you referring to the action of adding users to an Azure app (in this case Hornbill)? If so, I believe the ability to add groups (rather than individual users) requires Azure Active Directory Premium P1 or P2 edition. https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/assign-user-or-group-access-portal Dan  Link to comment Share on other sites More sharing options...
lee mcdermott Posted October 6, 2020 Author Share Posted October 6, 2020 @DanielRi thanks. I think it is now working for users who were already set up (must have been a delay in updating the settings once changed). Just need to test new users as I have a feeling these are not working? Maybe the account information is not the same mapping when created in office 365 to when we used google? Link to comment Share on other sites More sharing options...
Hornbill Staff DR Posted October 6, 2020 Share Posted October 6, 2020 Hi Lee,  unfortunately, I'm not sure I have enough information to comment. Does your last post still relate to the Single Sign On configuration in Azure, or are you now encountering an issue with users logging into Hornbill? I'll go with the most common situation when people get to this point. If there are problems logging in to Hornbill, it's usually due to the attribute being passed in the "NameID" element of the SAML Payload. Following an authentication attempt by a user, the identify provider (in this case Azure) will send a payload to Hornbill which tells us whether that authentication attempt has been successful or not i.e. the user is known to the identity provider. If it was Successful, this payload also contains other information including the "NameID". NameID is something defined in the SAML 2.0 standard, and Hornbill retrieves the value found in the "NameID" element and tries to match that against the "Login ID" property found in a Hornbill user account. So if you look at the contents of Login ID in a Hornbill user account, you'll know what Hornbill needs to complete the login for a user. Now we know that, how do we find out what the identify provider is giving us as the NameID, and how is this configured? This bit is done at the identity provider's interface, in the bit where you've configured SSO for the "App" (in the case of Azure) or the "Trust" (in the case of ADFS). As you can gather, each identity provider has a slightly different way of doing it (and the terminology might differ too). For Azure, once you've navigated to the SSO configuration related to Hornbill, you need to find the section titled "User Attributes and Claims" (https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization). Here you define what Azure sends to Hornbill in that SAML payload I talked about above. The Azure "Unique Identifier" is carried by the SAML payload as the "NameID" which in turn is matched against the Hornbill "Login ID" to complete the Single Sign On process. By default, Azure sets the userPrincipleName as the unique identifier. If you're coming from the world of Active Directory and ADFS, you'll likely have chosen the Login ID in Hornbill to be the samAccountName. As we know, the UPN and SAM Account Name are quite different in their content. Therefore if Azure is sending the UPN as the Unique Identifier, Hornbill wont find a match among the user Login ID's therefore the login can't complete. Fortunately, Azure still supports the samAccountName and it can be found in the list of attributes available for selection against the "unique identifier". It's called onpremisessamaccount (or something similar). Obviously, that's quite a specific scenario, but a common one given the path many are taking in the adoption of Azure. The crux of it is to make sure the identity provider is sending a value in the SAML "NameID" that matches what your Hornbill user accounts have as their Login ID. I hope that helps, it's certainly allowed me to get that knowledge out into the community! Thanks, Dan Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now