Refer to the SSO Implementation Process article for steps to follow when implementing an SSO.
Target users for SSOs include system admins and all users.
We offer a federated implementation with SAML version 2.0, or SAML2. SAML is a well-supported standard, published by the Oasis standards group, and provides federated authentication by redirecting a user’s web browser to an authentication server run by your company. Upon successful authorization, the user’s web browser is redirected back to the Collective with a security token. The security token is used to complete the authorization process.
If the SAML SSO integration is chosen, enable the SAML Integration feature on the Features page, then developers or IT personnel can configure the SAML service provider, identity provider (including certificate files), and attribute settings on the SAML Settings page in the Admin app. For technical details about configuring a SAML SSO on the SAML Settings page, refer to the SAML SSO Configuration article or the SAML Wikipedia page.
If you have a SAML SSO and edit the SAML information, you may receive an error message. If you receive this message, contact the Widen Central Support team for assistance with editing the SAML information.
SAML SSO for ADFS
The most common SAML implementation is with Active Directory Federation Services (ADFS). For technical details about configuring the SAML SSO for ADFS, refer to the SAML SSO Configuration for ADFS article.
Our implementation is tested against the Microsoft Windows ADFS product. Many other providers, including Novell and IBM, have SAML-compliant products.
If you choose the OpenID integration, enable the Google OpenID Integration feature on the Features page, then developers or IT personnel can configure the OpenID settings, including registration code and hosted domain, on the OpenID Settings page in the Admin app.
OpenID authentication is a well-supported standard published by the OpenID Foundation. The OpenID SSO integration works in a manner similar to SAML, where the user’s browser is redirected to an authentication server and back to the Collective.
Common identity providers include Google Apps for a customer’s domain and Windows CardSpace. Refer to the OpenID Wikipedia page for more information about OpenID.
Simple one-way portal login
The most simplistic SSO available is the simple one-way portal login. The one-way portal login allows one-way authentication from any system that implements the concept of individual authenticated users. It has been designed primarily for ease of implementation and follows several best practice data security policies.
Refer to the Simple One-way Portal Login SSO article for technical details about this SSO option.
Many companies have devised their own SSO infrastructure. In these cases, we will work directly with you to understand your integration requirements and assess the costs and timeframe needed. We have experience with many types of systems, including direct Lightweight Directory Access Protocol server queries, custom redirect and call-back-style systems, and many third-party authentication systems.
Simple one-way HTTP post
The simple one-way HTTP post method may be convenient when a corporate IT infrastructure does not support federated security for web apps, but there is an intranet or extranet portal system that tracks individual users.
A developer familiar with the portal would use directory information to create a “packet” of information that is passed to the Collective when a user clicks a link. Typically, the passed information includes the user’s first and last name and email address. Other information, like a per-user unique ID, mailing address fields, or security roles, can also be included. When the Collective parses the request, page flows may be included to collect additional user detail if the request does not include enough information.
We publish a separate document that details our preferred security features for this SSO method. Typically, we request that the data is encrypted via a two-way method (e.g., 3DES, AES, etc.) or that a keyed, hash-based message authentication code is used to eliminate URL tampering issues.