SSO - Troubleshooting

After you have configured SSO for Digital Pigeon, here are some common issues you may encounter, and their possible solutions.

SP-Initiated Sign-In not working for new users

When logging in to Digital Pigeon via the web (https://digitalpigeon.com/login) or via the Digital Pigeon App, and supplying a username of a new user that Digital Pigeon has not seen before, rather than redirect to the configured IdP, Digital Pigeon will ask for a password.  The password will not be accepted even if it matches the correct password of that IdP user.

What's happening?

Because Digital Pigeon has not seen the user before, it does not know it is associated with the Digital Pigeon account that has SSO configured.  It therefore follows the internal user login flow, and asks for an internal user password.  This will result in a 'Wrong email and password combination' error message.  (In fact, the internal error is 'User not found', however due to security best practices we do not reveal this in the UI as this information could be used in user-enumeration attacks).

How to fix?

The best way of ensuring that new users can log in via SP-Initiated Sign-In would be to read and follow the instructions in our Prove Ownership of a Domain KB article.  This will mean that all users with an email address that ends in your domain suffix will be associated with your SSO account, and will be redirected to the IdP to complete login.

If proving control of your domain is not possible, then you will need to instead ensure that new users login once using IdP-Initiated Sign in.  After this they can use SP-Initiated Sign-In.

To complete IdP-Initiated Sign-In, they must visit their IdP App Portal (e.g.: https://myapps.microsoft.com or https://yourcompany.okta.com/app/UserHome), and then click the Digital Pigeon App tile. 

User not assigned to the Application

After successfully completing IdP login (e.g. typing the username, password and completing any 2FA challenge), the IdP shows the following error:

Azure AD:

Okta:

What's happening?

In this case, the authentication is processed successfully, however as the error message suggests, the authenticated user has not been granted access to the Digital Pigeon application, either directly, or via their group membership.

How to fix?

If you are using groups to assign users, ensure that all your Digital Pigeon groups in Azure AD or Okta have the Digital Pigeon application assigned to them.  If you are not using groups, then ensure that all your users have the Digital Pigeon application directly assigned to them.

Logged in as a different user

When logging in to Digital Pigeon via the web (https://digitalpigeon.com/login) or via the Digital Pigeon App, you enter a username associated with an SSO enabled account, e.g. jane@yourcompany.com.  You are directed to your IdP SSO that immediately logs you in to Digital Pigeon without asking for your password or 2FA.  However, you notice that you're now logged in as chris@yourcompany.com rather than Jane's account.

What's happening?

This situation is likely to occur when an administrator is testing SSO, or in the case of a PC or mobile device that is shared amongst multiple staff.  It is not specific to Digital Pigeon and can happen with any SSO app.

The account chris@yourcompany.com must have been previously used and still has a valid session with the IdP.  Even if, as Chris, you had signed out of Digital Pigeon, the session with the IdP is still logged in, and any subsequent authentication flow that bounces to the IdP will reuse that session, without prompting for reauthentication.

How to fix?

If you are simply testing SSO, then you can ensure that when you switch users, you sign out of both Digital Pigeon and your IdP at the following URLs:

Azure AD: https://myapps.microsoft.com

Okta: https://mycompany.okta.com/app/UserHome

If you have users that regularly share devices and encounter this issue, or you are not satisfied with  relying on your users logging out of their IdP themselves, you can instead use the Force Re-authentication option in Digital Pigeon | Settings | SSO.

When this option is selected, your IdP is instructed to ignore any existing sessions and always ask for reauthentication.  As the warning text suggests, this will produce additional login prompts and may be annoying for your users, so please use this option with caution!

Refusing to provision new user

When logging into Digital Pigeon as a new user, using either SP-Initiated or Idp-Initiated Sign-In, you may encounter the following error message:

What's happening?

This situation can occur if the role is not being sent, or is not sent correctly by the IdP, and, the Default Role in Digital Pigeon | Settings | SSO is set to `Disable auto-provisioning when SAML role assertion missing`.

How to fix?

If you wish to control the role by your IdP, confirm that the 'role' claim is being sent correctly by your IdP when a user logs in.  There are a number of ways to achieve this, but here two examples of a working configuration for Azure AD and Okta:

Azure AD:

Okta:

OR, if you prefer not to send the role via the IdP, then instead change the Default Role in Digital Pigeon | Settings | SSO to 'User', or another level of your choice.

I want to add a samlbypass user

1. Provision the user via vis chosen SSO method
2. Contact us via help@digitalpigeon.com to set a password for that user
3. Get the user to samlBypass login and update their password
4. All done!