help.sitevision.se always refers to the latest version of Sitevision

Good to know about SAML

  • The SAML ticket is basically in XML format and there are both attributes that must be present and attributes that you choose and control yourself. More info about SAML ticket and SAML setup.

  • One of the attributes that must be included is NameID, which we usually refer to as the identifier. This attribute is the basis for how Sitevision identifies the user and links it to a user object in Sitevision.

  • When you have a federated login, Sitevision can neither read nor write to the directory. The only thing Sitevision can "know" about users is what is sent in the SAML ticket and is configured to be received through the SAML set-up. Read more about this under the title One-way communication.

SAML identifier selection

You choose what is sent as an identifier in the SAML ticket when setting up the idP and SAML configuration. You can choose between the different unique fields available for a user in your own directory. We recommend that you choose a stable identifier without direct personal data. The identifier in the SAML ticket does not have to be the same as the login username. The identifier is case sensitive; in other words, "kallekula" is not at all the same as "KalleKula".

Recommended identifiers

  • The identifier must be unique to the user and constant. Examples of constant identifiers are UUID, GUID or ID number (note that these are unappropriate if they contain personal data).

Inappropriate identifiers

  • An E-mail address is inappropriate as an identifier because it contains direct personal data, and is also considered unstable. For example, people get might married and change their last name and thus e-mail address - the identifier then changes.
  • The employee ID, CN, username, social security number and other personal data are not appropriate with regards to GDPR.

Change of SAML identifier

The identifier in the SAML ticket is the basis for the association between a user in the Federated Directory Service and SiteVision. Therefore, changes to the identifier result in SiteVision not being able to reconnect the user with the user item.

Some modules, such as booking, list favourites and web enrolment, depend on the user item, and these modules are affected by a change in the Identifier.

Social Collaboration

All changes to the identifier result in the creation of a new user item in SiteVision. Therefore, if the identifier is changed, the user will still be able to log in to SiteVision with the SAML ticket, but now get another user item. Therefore, on websites where Social Collaboration is enabled, the new user item will create a new social profile.

There are a couple of different scenarios for when the identifier changes.

  • You want to deliberately change what is sent as an identifier and replace the value that the directory service will send in the IdP
  • You adjust the identifier without knowing that it will have effects
  • Changes are made to the directory service, where the field used as an identifier changes for one or more users. For example, you might want to change all uppercase letters to lowercase, to achieve a standard.

In the first case, you can be proactive and, by ordering a job from SiteVision Product Support, get help to change the identifier of an existing user object so that users retain their old user identity and settings.

In the other two cases, the "damage" is already done. Sitevision Product Support can help to implement the changes of identifiers even then, but since ordering jobs need some advance planning, you may have to live with the fact that some or all users do not have their old user identities and lack settings for a period of time.

One-way communication

When your website has SAML as a login method, the connection between Sitevision and your directory service will be one-way. This means that if changes have been made to the catalog service, Sitevision will receive information about it when the user logs in again. The information* travels via the SAML ticket that accompanies the user at login.

* The information included depends on how SAML is configured on the IDP side.

What happens if a user is removed from the directory service?

By default, the user will remain on the website as Sitevision only receives information about updates upon login. You can disable the user by right-clicking on the user under the Users panel and selecting "Disable".

Is it possible to create an automatic sync between our catalog service and Sitevision?

Yes, it is possible to use the website's REST API to update Sitevision with changes that occur on the catalog page, provided that the catalog service supports listening for changes.

Methods that may be of interest:

  • SimpleUser - Create a new user before they log in.
  • EnableSimpleUser - Used to either disable or enable a user. A deactivated user is no longer visible under Site settings > Users but remains in Sitevision and is reactivated upon login. There is also a checkbox to use to list disabled users under Site Settings > Users.
  • UserIdentity - Used to create a social profile before the users first log in.

  • EnableUserIdentity - Used to either disable or enable a social profile. A disabled profile will not show up in a search, but will be searchable via the Find Person module if the "Search for inactive or hidden users" checkbox is checked.

  • ShowUserIdentity - Used to hide or show a social profile (when searching). All users are shown by default. A hidden profile does not show up in a search but can be searched for via the Search Person module if the "Search for inactive or hidden users" checkbox is checked.

  • Properties - Used to retrieve, edit and delete information about a SimpleUser. This is the method you should use to update things like phone numbers and email addresses.

  • AnonymizeUser - Used to delete a user and their information. Note that an anonymization cannot be reversed. If there are only a few users that you need to anonymize, we recommend the function found under Site settings instead. There you have a better overview and there is less risk of the wrong users being anonymized.

User items in Sitevision

Sitevision has two types of user item.

  • User - user objects that are created by a direct connection between the directory service and Sitevision, for example when running your own server.
  • SimpleUser - user objects of the type web user or a user created during federated login with SAML or OpenID Connect.

The users in the Sitevision Cloud catalog are of type User. Customers with their own catalog service in Sitevision Cloud have users of the type SimpleUser.

Information about the user is saved on the user item.

  • My favourites
  • Settings for the editor (language, text size etc.)
  • Any data from third party functions (e.g. script modules created by partners)

Social profile in Social Collaboration

If Social Collaboration is enabled on the website, a social user identity (UserIdentity) will be created by Sitevision for each user object that logs in. It is also possible to create a user identity by either right-clicking on a user under the Users panel and selecting the "Create user identity" option or by using the UserIdentity method in the REST API.

The user object and the social user identity have a two-way reference and are thus interdependent.

The social profile saves information associated with the user and Social Collaboration.

  • Profile image
  • Membership of groups
  • Notifications
  • And much more connected to Social Collaboration

The page published:

Did the information help you?