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 Frederick Zilmer, Brian Webb, Mariah Fry or Niusha Nawab about adding an entry.
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: LINK
Service configurations are used to establish connections to other services. Below is a list of the most common ones that we create and how we create them. To see a full list of each config and it's related properties as well as common issues, read this article.
- 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 if the client wishes to specify user access to certain parts of their SP. 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.
Below is an example of a common CMS User Role found in RAMCO:
For more details on setting up CMS User Roles, read this article.