When configuring Web Elements and SSO for our clients, we utilize a series of Service Configurations and CMS User Roles in addition to creating a separate widgetized website for the client's use. Here, we'll explain them in general.
Building a Widgetized Portal
If an association wishes to embed Cobalt widgetized Web Elements, they will need a widgetized portal. Note that Web Elements aren't required for SSO.
The widgetized portal is nearly identical to the standard portal but includes some differences.
To confirm that a client has a widget site:
1) Navigate to the server that contains their portal site and portal folder.
2) Open Internet Information Services (IIS) Manager. Navigate to the App Pools
3) Confirm that there is a site in the list with a name like [association]widget.[domain] (i.e. ctrwidget.ramcoams.net)
If there isn't, you'll need to go through the process of creating a Widget site. Here is a link to an article on that process
Once you've confirmed or created the site, you'll need to confirm that the site has a DNS Entry:
1) Open Command Prompt on your desktop
2) Ping the URL by entering and running this command: ping [association]widget.[domain]
3) Confirm that you receive results:
If you don't receive results, speak to your manager about adding a DNS entry. If you need make the entries yourself, here are steps.
Once you've created the site and the DNS Entry has propagated, if you navigate to the widget site's URL, you should see this error, which occurs because of a missing service configuration:
If you don't see this error, refer to this article for troubleshooting steps you can take before contacting support.
Service Configurations
Service configurations are used to establish connections to other services. Below is a list of the most common ones that we create and their function.
- Widget Site Service - This Service Configuration Property (Service Config) is needed to complete the setup of the widget site
- API Service - This Service Config is needed if the client is using our API to pull information for their SP, for instance, if they're using Sitefinity as their CMS
- SAML Identity Provider Service - This Service Config is needed to establish Dynamics as the SAML Identity Provider
- SAML Single Signon Service - This Service Config is needed to establish Dynamics as the SAML Service Provider, specifically for a Clareity integration
- Higher Logic Integration Service - This Service Config is needed if the client is specifically using our API to pull information for Higher Logic
CMS User Roles
CMS User Roles are used to specify user access to certain parts of their Service Provider. For instance, they may wish for all active contacts to be able to see the committees information but only for active members to have access to the store. This can get more granular but, often, the most important role is the admin role, which allows contacts or users in Dynamics to access the SP backend. This is so that association staff can edit content on the site without needing an extra set of credentials and URLs.
For more details on creating CMS User roles, see this article.
A client may choose to use a widgetized portal because they want a user to experience two sites as one or they may choose to stick with the standalone portal because they prefer the user to recognize the two sites as different but still want them to have the seamless experience of using an SSO. In either case, for details on how to configure any of the combinations of these configurations, refer to the articles below:
1) Cobalt as IDP, WordPress site as SP
2) Cobalt as IDP, Sitefinity Site as SP
3) Clareity as IDP, Cobalt as SP
5) Cobalt as IDP, Higher Logic as SP