Single Sign-On (SSO) via SAML 2.0¶
Single Sign-On is a process that allows your organization’s network users to access authorized network resources without needing to log in separately for each resource. Instead of entering a username and password inside PolicyStat, if your users are already logged in to your network, they can receive seamless access to PolicyStat. SSO shortens the distance between your users and the work that they need to do.
Reduced Administration Costs¶
By eliminating the need for multiple usernames and passwords, PolicyStat Site Administrators receive fewer requests for forgotten passwords and account information.
Increased User Adoption¶
By saving 5-20 seconds on each login attempt, your staff is much more likely to regularly use PolicyStat. This results in more up-to-date documents, better sharing of best practices, and wider dispersal of your important information.
SSO integration allows your specific corporate password policies to be enforced. By eliminating the potential for re-use of passwords and the need to memorize a new password, it also supports stronger passwords in general.
Q: What SAML 2.0 Identity Providers (IDPs) does PolicyStat support?¶
A: PolicyStat has specific support for:
Q: Is SAML 2.0 SSO included with Active Directory integration?¶
A: SAML 2.0 SSO integration and Active Directory Integration are completely separate options. You can choose any combination of:
- Neither option
- Just SAML 2.0 SSO
- Just Active Directory integration
- Both SAML 2.0 SSO and Active Directory integration
Q: What is the advantage of having both SSO and Active Directory integration?¶
A: On top of the benefits of SSO, Active Directory Integration adds:
- Nightly user provisioning and de-provisioning
- Email group (distribution group) synchronization
Q: If I choose SSO, but not Active Directory integration, how are users provisioned?¶
A: If you choose not to combine SSO with Active Directory Integration, there are three alternatives for user provisioning:
- Instruct users to login to PolicyStat and take advantage of Just-In-Time Provisioning. This eliminates the need to manually create user accounts, but requires the user to log in at least once before they can be given permissions, assigned to documents, added to approval workflows, etc.
- Site Administrators can manually create user accounts via PolicyStat’s User Management functionality, just as they could in the absence of SSO.
- You can take advantage of our File-Based User Integration option to periodically perform a bulk update of all user accounts. This feature has the added benefit of support for deactivating user accounts, but it usually requires IT involvement to produce the necessary file containing desired user accounts.
Note: With SSO, users will never be able to login to PolicyStat once they’re deactivated in your organization’s SAML identity provider, but their user accounts will still appear in PolicyStat until they’re either manually deactivated by one of your Site Administrators or deactivated via File-Based User Integration.
Q: What is Just-In-Time provisioning?¶
A: Just-In-Time provisioning allows user accounts to be created “just in time”, meaning on their first login. Without SSO and Just-In-Time provisioning, a Site Administrator must manually create a user’s account before that user can log in. With SSO enabled, any user that has a valid account on your organization’s corporate network will automatically be able to log in to PolicyStat with the default read-only permissions on active, approved documents.
Implementing SAML 2.0 SSO¶
SAML 2.0 SSO integration with PolicyStat can be a completely self-service process.
Note: If your organization is implementing SAML 2.0 for the first time, it’s worth considering PolicyStat’s SSO Integration Consulting Package.
1. Request SAML 2.0 SSO access¶
Contact PolicyStat customer support and request SAML 2.0 SSO Access. We will then enable it for your PolicyStat libraries.
2. Configure your SAML 2.0 Identity Provider (IDP)¶
SAML 2.0 integration requires that your organization has a working Identity Provider (IDP). A common IDP is Windows Active Directory Federation Services.
3. Use PolicyStat’s “Single Sign-On Configuration” to configure necessary parameters¶
First, login to PolicyStat using a user account with Site Administrator permissions. If you’re a member of your organization’s IS team and don’t already have a PolicyStat account with those permissions, you can request one from your PolicyStat Site Administrator. Once logged in, navigate to the Admin tab and then to the Single Sign-On Configuration page.
The information on this page will allow you to add PolicyStat as a SAML 2.0 “Service Provider.” If you’re using Windows Server ADFS, you will be adding PolicyStat as a Relying Party Trust.
Q: Is PolicyStat an Identity Provider or a Service Provider?¶
A: PolicyStat acts as a SAML Service Provider and relies on your existing Identity Provider.
Q: Does PolicyStat support Single Logout Service?¶
A: No. PolicyStat does not currently support Single Logout Service.
Q: Does PolicyStat support IDP-initiated SSO?¶
A: Yes. PolicyStat does support IDP-initiated SSO.
Q: What SAML 2.0 bindings does PolicyStat support?¶
A: PolicyStat only supports HTTP POST binding. HTTP Redirect is not supported.
Q: What configuration information is required?¶
A: You will upload your IDP metadata XML file. You can also customize the attribute mappings for:
- first name
- last name
- email (optional but highly recommended)
- title (optional but highly recommended)
SSO Integration Consulting Package¶
If your organization is unfamiliar with SAML 2.0 integrations, PolicyStat offers an optional consulting package to ensure implementation success. In addition to the available documentation and email support, this package includes phone support specific to your SAML 2.0 configuration. We can help you work through the implications of SAML 2.0 for your organization, including the trade-offs between security and ease of use.
This package is completely optional. If your organization has already performed an SAML 2.0 integration with an application other than PolicyStat, you almost certainly do not need this package.
For customers implementing their own IDP, or who are using their IDP for the first time, this package is recommended. In addition to providing access to PolicyStat’s SP for testing, PolicyStat will help debug errors that you encounter.
This consultation does not include the implementation of an IDP. That requires on-site time and technical expertise that we’re unable to provide. PolicyStat can help recommend paths towards the implementation of an IDP, though, including vendors, libraries and tools.
For pricing on this consulting package, please contact email@example.com