Introduction and general configuration


Together with Identify*Admin and Identify*Runtime, Identify*UserProv is a core component of Safewhere*Identify. It is a web-based user self management software, that connects to the Safewhere*Identify user storage. It provides organizations a highly configurable method in which to provide their users with sign-up services and self management of personal data, including password self-service functionality.

The software makes it possible to set up three types of pages:

  • Sign-up pages (aka. ”Create” page) – pages that support users adding themselves to the Safewhere*Identify user storage.
  • Self management pages (aka ”Edit” page) – pages where users can modify their personal data.
  • Password self service pages (aka “Password” page) – pages where users can change their password.
  • Styled edit pages that can be embedded (aka “EmbedEdit” page) – Self management pages that can be embedded into an iframe.

A site may hold as many pages as is required. Users that are not identified as existing in the Safewhere*Identify database, will not be shown the self management and password self service pages, whereas users who have identified accounts in the database will not be shown the sign-up pages.

Rules may be set up for each of the pages, which further limit the users that should be granted access to them. This makes it possible to e.g. make different signup pages, that are shown to a user depending on the claim values of his token. As importantly, having different pages for different user profiles also means that you can use UserProv to grant them different rights and roles upon registration.

Setting up the database connection / core configuration

You will find the core configuration options for your UserProv installation in the configuration file called UserProvCoreConfiguration.config. Below is an example of how this may look:

  • domain: is the Identity Provider Domain Url which we will send Rest API request
  • restApiPath: is the Identify API path. Keep it as-is.
  • accessToken: is the Rest API access token that generate by Identity Provider tenant. To create it, please take a look on:
  •  identifyNameClaimType: specifies the claim type whose value will be used for the user’s Identify Name.
  • userDisplayNameClaimType: specifies the claim type whose value will be used for the name display at Userprov.
  • sourceIdentityBearingClaimType: is the Claim in the upstream IdP where we will use its value to verify against the one at the Identify claim to define whether a user already exists in Identify or whether it is to be treated as a new user.
  • destinationIdentityBearingClaimType: is the bearing claim in the Identify database that will be used to identify whether a user already exists in Identify or whether it is to be treated as a new user
  • destinationEmailClaimType: specifies the Claim in Identify that is used to store a user’s email. This is important in order for UserProv to be able to send the user an email with a password.
  • destinationSmsClaimType specifies the Claim in Identify that is used to store a user’s mobile phone number. This is important in order for UserProv to be able to send the user an SMS with a password.
  • unsupportedMessage specifies the message that a user gets if he logs into UserProv and the system cannot find any pages that should be shown to him.

For further configuration of Email, you should open the file EmailConfiguration.config, which looks something like the following:

EmailConfiguration node includes templatePath, which is the path where the emails to be used are stored, as well as testAddress, which all emails will be sent to when not empty.

The template used for email is named sendPasswordTemplate.xml and is located in the EmailConfiguration templatePath.

Under Servers node you can find the email servers that are supported by the system. One of the servers are specified as the default, meaning that it will always be used until you change default in the config file.

Each added mail server has a number of standard email server settings that will not be explained further.

For SMS we just send his password to his phone number. The configuration of the SMS service can be found in the file HttpRequestSmsGatewayConfiguration.config in the folder \Themes\Default\Settings. Below is an example of this file:

General Site Configuration Settings

All settings below are set up in the web.config file. Most things in this file you do not want to change. But there are a few settings you can influence.

  • UserProv: All site specific configurations can be moved to a folder of choice. When creating a new Theme for the application, the settings in Web.config is the only thing that needs to be changed. Move the files to a /Themes/<Customer>/Settings/ folder and change the paths in this section.
  • <microsoft.identityModel>: Setting up the site in a federation requires you to set up values in this section.
  • All settings below are set up in the UserProvConfiguration.config file.
  • GlobalizationRelativePath: Specifies the file that holds text resources and culture settings. Only used marginally so far but will be extended in future versions of the application.
  • LogConfigurationFileName: Specifies the file that holds information on how logging is done.
  • FormatProviders: Currenty, not in use.
  • RegularExpressions: Holds expression validation rules incl. Error messages. These regular expressions can be referred to when setting up fields in the pages. Read the chapter on Attributes to understand this in detail.

General Page Configuration Settings

All settings for this chapter are set up in the UserProvPagesConfiguration.config file.


This section holds information of all the claims that will be used in UserProv, independent on the pages on which they are used. Below is an example of the Attribute section:

Each attribute is defined by a number of parameters as explained below.

Parameter Description
Name The unique name the claim will be referenced by in other sections of the configuration file. Just needs to be unique for the site.
destinationClaimType The Identify claim.
sourceClaimType The incoming claim type, if any, whose value is picked up for this attribute.
resourceKey Leave it as-is with the default value: UserAdministration_UserName
displayName The label that will be shown for the claim in the page.
helpText The text that will be shown together with the label to explain what value is expected from the user for the field.
userInterfaceOption Choice among: Mandatory , Optional, Hidden, ReadOnly. Defines whether a value needs to be specified for the claim type in order for the user’s information to be saved. Hidden implies optional, but please do be careful to remove also expression validations if you want any value in the field to pass straight through.
Syntax The way in which text is shown in a field in the user interface. There are five options: UnicodeString;Password;Label;LabelPassword;ReadmePlease note: Label;LabelPassword;Readme are used for the embedded page.
regularExpressionName Defines the way you want to validate the value following a regular expression rule. The possible options are placed in the Identify database in the table called SharedConfigurableSetting.

Below is an example of how some of the settings are shown on the user interface.Identify UserProv - General page attribute UI

Password Configuration

The password configuration section is found in the UserProvPagesConfiguration.config file. It defines different possible systems for setting up password rules.

Parameter Description
Name A unique name that the rule will be known by. Not shown in the user interface.
Autogenerate When true, system will generate password as configured in PasswordConfiguration.config file – this file is at the root web folder.
sendPasswordBy Defines the way in which autogenerated passwords are sent to the user:EmailSmsBothEmailFirst: Send by Email if both Sms and Email availableSmsFirst: Send by SMS if both Sms and Email available

Page Configuration

Each of the three page types will be explained in turn below. Notice, that there is no restriction on the number of pages that may be added of each type. This gives you a whole lot of flexibility, since you may customize various versions of e.g. the edit page, depending on the type of user registered in the incoming token. You may even use it to split up the information for the same user into several pages, e.g. a page for personal information, a page for choice of roles, etc.
Each page that a user has access to see will be shown as a tab in the UserProv site.

Identify UserProv - page shows to user

All pages have their own seperate parent node type. The order in which these are placed in the UserProvPagesConfiguration.Config file will also be the order in which they appear as tabs in the system.

  • Sign up pages are identified by the node: <PageCreate>
  • Self management pages are identified by the node: <PageEdit>
  • Password Self Service Pages are identified by the node: <PagePassword>


Was this helpful ?Good Somewhat Bad