Jump to content

Azure Single Sign On

lee mcdermott

Recommended Posts


We are trying to setup SSO with AZURE. We have it working by adding individual users to the Hornbill Application Group in Azure.


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.




Link to comment
Share on other sites

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.



Link to comment
Share on other sites



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

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!


Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...