We offer several standard methods of single sign-on (SSO) integration, including Security Assertion Markup Language (SAML), Google OpenID, simple one-way portal logins, and custom SSOs. SSO integrations can be used to make logging into the Widen Collective seamless and to create user accounts, authenticate users, and map user roles from internal databases.

You'll work with your system admin and customer success manager to determine the preferred SSO integration and implement it on your Collective site. If you've chosen a SAML or OpenID integration, either can be set up by system admins in the Admin app after you enable the appropriate feature on the Features page. For custom SSOs, developers from both Widen and your team communicate back and forth until the SSO is implemented.

Two-factor authentication will be in place if your integrated SSO method has it in place.

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.


SAML

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.


Google OpenID

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.


Custom SSOs

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.