With the Belkast solution:

  • Secondary accounts are identified and linked to their owner’s Primary account.
  • Secondary accounts are governed by an identity lifecycle – with options to remove, reassign, or transfer the access and privileges.
  • Secondary accounts may be managed through authoritative source events on the Primary account – and through workflow / lifecycle processes.

The solution we have developed is truly unique and is based on the standard NetIQ Identity Management product; the following capabilities have been implemented:

Account Management

Account Transfer

A Secondary Account can be transferred from one owner to another, either automatically or manually. The automatic Use Case is when the owner, or Primary Account, is Terminated. This termination can be configured to happen when, for example, the Primary Account goes to an EmployeeStatus of X or D or No Longer Employed. The lookup table can be configured to define what a termination actually is.The manual Use Case is when the Trigger attribute is updated with transfer-account|<account-type>|<account-name>|<new-owner>

When a Secondary Account is transferred, there are a few things that can happen…and they can all be configured per ‘account-type’:

  • Data can be copied from the new Owner to the Secondary Account
  • If desired, a new password can be assigned to the Secondary Account
  • If desired, an expiration date can be assigned to the Secondary Account; this logic is driven off data present on the new owner

All of these events can be configured in a lookup table row assigned to each ‘account-type’.

Resource Model

SAML can be configured to work with or without the NetIQ User Application Resource Model. If you don’t have the User Application, no problem. Just flip a GCV and the SAML Connector will take care of the rest.

In the situation where the User Application is not being used, SAML will replicate the content of the nrfAssignedResources attribute, thereby ensuring that there are no code changes to be made when changing to the non User Application model.

Account Creation

To create a new Secondary Account, you can assign a resource to a User from within the User Application. Because the outcome of the User Application resource assignment is an update to the Trigger attribute, you can also just update the Trigger attribute directly on the User Object.

The format of the value to insert in the Trigger attribute is assign-resource|<account-type>|<account-name>. For the account-name portion, you can supply your own value or use [] to generate a name based on the setting in the lookup table for the account-type.

Either of these two methods will result in the creation of a Secondary Account.

Account Deletion

To delete a Secondary Account, either revoke the Resource from within the User Application ( with the correct settings present in the lookup table ), or just delete the Secondary Account using an LDAP browser.

However, please note that the revocation results in the deletion, the disabling, or the transferring of the Secondary Account based on the lookup table settings.

Primary Account Termination

When the Primary User Account is terminated, SAML really comes in to its own. The trigger which kicks off a termination is based on an attribute change; for example, employeeStatus changing to INACTIVE or termination date gaining a value.

Based on the settings in the lookup table, the Secondary Accounts owned by the Primary Account will be Disabled, Transferred, or Deleted.

When a Secondary Account is Transferred, you can configure SAML to ensure that the data from the new Owner is copied over to the Secondary Account.

Data Flow

Attribute Synchronization

A value in the main lookup table is assigned to each ‘account-type’, with the value pointing to a child lookup table. This gives SAML the flexibility to share data synchronisation models between multiple types of Secondary Account. Attribute synchronisation can be configured for:

  • Primary account -> Secondary account
  • Secondary account -> Primary account
  • Secondary account <-> Primary account
  • Attribute reset

Required Attributes

Required attributes can be specified for the creation of a Secondary account. Similar to the built-in function veto-if-required-attribute-not-available, SAML uses a lookup table to determine whether an attribute is required before a Secondary Account is created. Attributes can be added and removed on-the-fly. The required attributes setting is per account-type.

Default Attributes

Default attributes can be assigned on the creation of a Secondary account (per account-type). This is simply a case of updating the relevant row in the lookup table. For example, you can assign one or more Entitlement values when a new Secondary Account is created.

Other Features

  • Lock down of Secondary account request based on attribute data (Department, Job Code, etc.)
  • The Secondary account can be placed in a predefined Organizational Unit (per account-type)
  • The Secondary account can be assigned an expiration date (per account-type)
  • A Primary Account can have as many Secondary Accounts as the lookup table is configured to allow
  • A maximum number of Secondary Accounts can be defined (per account-type)
  • Secondary Accounts can be blacklisted: if account type A then not account-type B

Representation of Primary Account Data

The image below shows a representation of the data held on the Primary account. There are a couple of attributes on the Primary account that tie the data synchronisation together: There is a DirXML-Association value per Secondary account (not visible in the image) and there exists the Distinguished Name (DN) of the Secondary account in the idamSecondaryAccountDNs multi-valued attribute. You might also notice in the image that the nrfAssignedResources attribute has a couple of values – the number of values just happen to correspond with the number of Secondary accounts assigned to the Primary account.

Representation of Secondary Account Data

The image below shows a representation of the data held on the Secondary account. Once again, there is a DirXML-Association value linking the Secondary account with the Primary account (not visible in the image), there exists the Distinguished Name (DN) of the Primary account in the idamPrimaryAccountDN single-valued attribute, and the relevant value contained in the nrfAssignedResources attribute from the Primary account is also held on the Secondary account in the idamAssignedResource attribute.

What makes this offering unique and a proper Solution is the fact that, as well as the SAM Connector code, we have also developed several sophisticated Roles Based Provisioning Module (RBPM) Workflow forms to facilitate the requesting and maintaining of Secondary accounts.

Request Form 1

Request Form 2

Email to Line Manager

Approval by Line Manager

Approval by Service Desk

Email when the request is approved

Email when Secondary account is created