Skip to content

Custom attributes

Custom attributes contain user-related information that does not fit a regular profile. Additional pieces of information can be stored as a custom attribute. Depending on Onegini IdP configuration, they can be mapped automatically from the identity provider or entered manually by the user in the registration flow. Also it is possible to amend attributes via API call

Custom attributes mapping

Custom Attributes can be mapped as easily as regular attributes in the identity provider configuration section. Please check Attributes mapping topic guide for more information.

Custom attributes on the sign-up page


In order to make it possible for end-user to enter custom attributes on the sign-up page, they have to be properly configured. Identity provider configuration form allows doing that in "Custom Attributes" section. Following elements should be configured:

  • Name - custom attribute name. If value is supposed to come from external identity provider then the name should match "mapTo" column of Custom Attribute Mapping table.
  • Type - type of custom attribute. All types are stored as a string, but this option might be useful in presentation and validation layer. Right now Onegini IdP supports: text, number, checkbox
  • Editable - information whether the user should be able to edit this field. It is passed to model map and template should consume it to make field disabled or not. Regardless of frontend implementation, non editable fields will be overwritten in backend when they are changed in frontend.

It's always recommended to consider which of them should be displayed in the sign-up form and which should be just mapped automatically because they might contain sensitive information.

Sign-up form template

Configured custom attributes are meant to be displayed on sign-up page. In order to do that model map is enriched with configuration object customAttributes - list of custom attributes configuration elements. Example:


Custom attributes are mapped to form as Map this means that proper binding can be done by:


Example template implementation for different types:

<section th:fragment="customTextAttribute(attributeConfig)">
  <input type="text" th:id="${} + 'CustomAttribute'" maxlength="2000"

         th:autofocus="${#fields.hasErrors('*') == false}"


<section th:fragment="customNumberAttribute(attributeConfig)">
  <input type="number" th:id="${ + 'CustomAttribute'}" maxlength="2000"

         th:autofocus="${#fields.hasErrors('*') == false}"


<section th:fragment="customCheckboxAttribute(attributeConfig)">
  <input type="checkbox" th:id="${ + 'CustomAttribute'}"

         th:autofocus="${#fields.hasErrors('*') == false}"


Basic validation is provided (fields length). Additional validation can be implemented in frontend (javascript).

Custom attributes fields can be enriched with proper labels and hints. Example:

<label th:for="${ + 'CustomAttribute'}" class="control-label"
<i class="icon icon-info-sign" style="position:absolute" th:title="#{personal.signup.custom-attributes.__${}}"
 title="field help" data-onegini-toggle="tooltip"

 th:if="${#messages.msgOrNull('personal.signup.custom-attributes.__${}') != null}">


To ensure that messages will be properly resolved, they should be configured as custom messages in Admin Panel. Please read more in here Example custom messages:

personal.signup.custom-attributes.customAttribute1=Custom Attribute Attribute info message that will pop out near label


Please bear in mind that fields of attributes mapped from identity provider in some cases might not be filled with values or values might be malformed. In this case, user won't be able to update them so the chances are that the user won't be able to submit the form and finish up the registration process.