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 who are not identified as existing in the Safewhere*Identify database are not shown the self-management and password self-service pages, whereas users who have identified accounts in the database are not shown the sign-up pages.

Rules may be set up for each of the pages, which further limit the users who should be granted access to them. This makes it possible to, for example, make different sign-up pages, which are shown to a user depending on the claim values of his token. In addition, 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

ou 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: specifies 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: specifies 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 in to 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:

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

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

Under the Servers node, you can find the email servers that are supported by the system. One of the servers is specified as the default, meaning that it will always be used until you change the 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. Although you won’t want to change most things in this file, 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 are 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. It is 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: Currently, not in use.
  • RegularExpressions: Holds expression validation rules, including 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 on all the claims that will be used in UserProv, independent of 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 Currently with the 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. It 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 be careful to remove 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 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, the system generates the password as configured in the PasswordConfiguration.config file—this file is at the root web folder.
sendPasswordBy The way in which autogenerated passwords are sent to the user. EmailSmsBothEmailFirst: Send by email if both SMS and email are available and availableSmsFirst: Send by SMS if both SMS and email are available.

Page Configuration

Each of the three page types are explained below. Notice that there is no restriction on the number of pages that may be added of each type. This gives you flexibility because you may customize various versions of, for example, 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, for example, a page for personal information, a page for choice of roles, and so on.
Each page that a user has access to see is shown as a tab in the UserProv site.

Identify UserProv - page shows to user

All pages have their own separate parent node type. The order in which these are placed in the UserProvPagesConfiguration.Config file is also 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>