What are Profile Attributes?


Located under the Access Control administrative section, Profile Attributes are data fields that are attached to your users that are either defined by your user database or created by you the Administrator. We can split Profile attributes into two clear distinct sections.

1. Realm Attributes

These are fields that are provided by your user database, for example Active Directory attributes such as Surname, Street Address, Telephone etc. In your Hypersocket product you have full control over what Realm Attributes your users can view and can optionally allow them to self-service their own profile by editing these attributes.

When editing the Realm Attributes for your database you may set any attribute as Editable or Visible. If set to Editable your users will not only be able to see these in their Profile page but also update them. In order for a user to update their profile they do require the Profile Update permission as a part of their Roles. If the user only has Profile Read then the Editable attributes will revert to being Visible and cannot be changed.

Visible attributes will always be read only. 

If you remove both Profile Read and Profile Update from a user they will no longer be able to access the Profile page.


2. Custom Attributes

These are additional attributes that you define to extend the information held about your user. For example these could be the username and passwords for external services that are accessed through your Hypersocket product. 

Each Custom Attribute is assigned a Custom Category. When viewing your users profiles, you will notice that each Custom Category you create appears as a new tab in the users profile. 

To create a new Custom Attribute click the Create button and complete the form.

Provide the attribute with a Name, this will serve as the label that your users will see in their profile. 

At the time of writing, there are two Types of Custom Attribute that you can create, either a Text field, or Password field. All the options are available to both field types, the difference being that a Password field will be masked when the end user enters the value and cannot be seen.

The Variable Name is important because this can be used elsewhere in the system to place the attribute in resources. The attribute name should be something unique across all other attributes, we recommend you use an identifier with no whitespace. For example if your attribute is for "Webapp Password" and ideal variable name would be "webappPassword".

Most areas that accept replacement variables have the  icon at the end of the field. If you want to manually use the replacement variable in an area that supports it you write the variable name wrapped in ${}, in our previous example we would have used ${webappPassword}

Most attributes would not need a Default Value, however you could use this when creating an attribute that might have a common default value.

In the Description field place a suitable prompt to let your users know what the attribute is for. If the user is allowed to edit or see this attribute this will be displayed as the help text for this field. 

On the Options tab you can then define the Scope of the attribute. A User scope attribute will be visible to the end users you assign the attribute to. An Admin scope attribute will be visible only to the Administrator, on the user profiles that you assign the attribute to. 

For example, if you do not want the user to know a particular password for a service they have access to you should set the attribute as Admin scope. If you want the end user to provide the password themselves, set it to User scope.

You can optionally make an attribute Read Only

If you enable the Encrypted option, any value the user or Administrator enters in the users profile will be encrypted so that anyone accessing the raw database will not be able to view the original data.

It is recommended that you encrypt all password and secrets defined as attributes.

The Weight field helps you position the field on the users attribute when there are multiple attributes in the same category. The lower the weight, the higher it will appear on the page.

Finally assign the attribute to a Role(s). Only users within these Roles will have the attribute available to them.

Once you have clicked Create to save the Custom Attribute, it will be immediately available on your users profiles.



I have shown how you can use the Profile Attributes section to expose attributes of your user database for user self-service and also how to create custom attributes to extend the data stored for users.

Have more questions? Submit a request