You are getting JWT Single Sign-On (SSO) set up for your account, but how do admins sign in with JWT SSO? You have two options, and we'll walk you through both. (JWT SSO only. For other SSO protocols you must use our API -- you can add your feedback to our Idea for SCIM provisioning here.)
Granting and Denying Access in the SSO Token
If you pass admin:accept in the SSO token, this will make someone an admin. So if someone is not already an admin on your UserVoice account, and they pass admin:accept in their SSO token, they will become an admin.
Along with changing the user's license to Admin, it will also assign the following permission set:
- Capture feedback: Always on (default)
- Internal Roadmap: Can view & edit roadmap content
- Idea Management: Can view & edit ideas
- Settings: Can edit account settings only
Note: You cannot set more granular permissions with this method. They must be set manually in the Users and Permissions, in the Admin Console, or with the Admin API. We have an idea on our forum to add more granular permissions. You can add your vote here.
If they are already an admin in UserVoice, admin:accept will allow them to sign into the admin console via SSO. If you pass admin:deny, they will be removed as an admin. Use this option if you want to grant and revoke admin privileges when they sign in via SSO.
How Admin:Accept works
- You don't have to use this option to grant admin privileges
- If you don't pass admin accept or deny in the token, that's fine. Admin privileges won't be granted or removed. It's not required.
- If you remove someone as an admin in UserVoice, but their SSO token still passes
admin:accept, they will be made admin again.
Granting and Denying Access in your UserVoice Admin Settings
You want to invite and manage your admins in UserVoice, but still have them sign in with SSO.
And you can, but you will need to pass trusted:true in their SSO tokens. This basically tells us you've verified the identity of the user, and they really are Admin John Doe. All trusted:true tells us is that the user is who they say they are.
How Trusted:True Works
- If an end user signs in with
trusted:true, they won't get access to the admin console. - If an admin signs in with SSO and passes
trusted:true, they will have access to the admin console. - If you remove someone as an admin in UserVoice, when they sign in again, they won't have access even if they are passing
trusted:true.
(Why require trusted:true? Not all companies verify the identity of users when they sign in. So a user could potentially sign in with an admin email address, and we don't want them gaining access to the Admin Console just because they are using someone else's email. So you only want to use trusted:true if you verify the identity of your users.)
So if your admins will be signing in with SSO, make sure they pass trusted:true or admin:accept. If they don't, they won't be able to access the admin console.
How to set it up
Check out this article for the technical details on getting this set up.
Wait! I don't want my admins to sign in with SSO at all!
Your admins don't have to sign in via SSO if you don't want. They can sign in with UserVoice's default log in system by going to your yoursubdomain.uservoice.com/admin.