Skip navigation
All Places > Products > RSA SecurID Access > Blog > 2016 > October
2016

User Attributes

In SecurID Access Change Attribute Mapping Name in Identity Sources we talked about how we can change attributes names. We also mentioned that we can change the attribute type, here was the use case:

  1. Change the Target Attribute Type of a Discovered attribute
    1. Let's say you wanted to treat a date as a string to use other policies operations

Let's go into this scenatrio

Changing The Attribute Type

Depending on the type of the attribute we have certain policy operations available. Here are the available types:

  • datetime (accountExpires)
  • string (mail)
  • long (badPwdCount)
  • boolean (isDeleted)
  • double ()

If an attribute is of type datetime we can use the following policy operations on it:

  • Equals
  • Does not equal
  • Greater than
  • Greater than or equal
  • Less than
  • Less than or equal
  • Is null
  • Is not null

 

 

If an attribute is of type string, we can use the following policy operations on it:

  • Contains
  • Does not contain
  • Matches
  • Does not match
  • Starts with
  • Ends with
  • Equals
  • Does not equal
  • Is empty
  • Is not empty
  • Is null
  • Is not null
  • Set contains any
  • Set does not contain any
  • Set contains all
  • Set does not contain all

 

If an attribute is of type long or double, then we have the following policy operations on it (same as datetime):

  • Equal
  • Does not equal
  • Greater than
  • Greater than or equal
  • Less than
  • Less than or equal
  • Is null
  • Is not null


If an attribute is of type boolean, then we have the following policy operations on it: 

  • Equal
  • Does not equal
  • Is null
  • Is not null

 

So let's say I wanted to do a string match operation on a datetime attribute, like accountExpires, by default you saw what operation are available above. So let's change the type mapping to string:

Now after making that change, if I choose that attribute I can have more policy operations:

Different Attribute Type for the same Attribute

Let's say we have two attributes with the same name but the types are different. Let's use the same example as before and utilize the mail attribute. I went ahead and changed the type on one of the identity sources to be boolean while I left the other one to be string:

and here is the other one:

Since both attributes are seen as one, when I check out the policy operations available for that attribute it actually only lists operations that apply to both:

User Attributes

After you add an Identity Source, the IDR connects to the AD or LDAP Server and parses all the available attributes. On the User Attributes page of the Identity Source, you will see a list of the discovered attributes:

You will also notice that next to each attribute there is a Mapping column with a pencil next to it. Upon clicking on that pencil you are able to change the Attribute Mapping:

There are a couple of use cases for changing the attribute mapping:

  1. With Multiple Identity Sources you can combine attribute names by setting their Target Attribute Name to be the same
    1. For example in AD you have sAMAccountName and in an LDAP server you might have uid
  2. Change the Target Attribute Type of a Discovered attribute (this is actually covered in SecurID Access: Change Attribute Mapping Type in Identity Sources)
    1. Let's say you wanted to treat a date as a string to use other policies operations

Let's check out the first scenario.

Combine Attributes Names

I have two Identity Sources, an LDAP server and an Active Directory server. In AD I use the sAMAccountName attribute for the User IDs, and in my LDAP server I use uid for User IDs. I have the same User ID in both Identity Sources:

~> ldapsearch -LLL -h 10.210.0.149 -D "administrator@singlepoint67.com" -W -v -b "CN=Users,DC=singlepoint67,DC=com" -s sub "(sAMAccountName=karim)"
ldap_initialize( ldap://10.210.0.149 )
Enter LDAP Password:
filter: (sAMAccountName=karim)
requesting: All userApplication attributes
dn: CN=karim demo,CN=Users,DC=singlepoint67,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: karim demo
sn: demo
physicalDeliveryOfficeName: karim@elatok.tango.net
givenName: karim
distinguishedName: CN=karim demo,CN=Users,DC=singlepoint67,DC=com
instanceType: 4
whenCreated: 20150406235849.0Z
whenChanged: 20160930162317.0Z
displayName: karim demo
name: karim demo
logonCount: 0
sAMAccountName: karim
sAMAccountType: 805306368
userPrincipalName: karim@singlepoint67.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=singlepoint67,DC=com
mail: karim@demorsa.com

And here are the regular and operational attributes for same user in the LDAP Server:

 ~> ldapsearch -LLL -h 10.210.0.206 -b "dc=singlepoint66,dc=com" -D "CN=directory manager" -W "(uid=karim)"
Enter LDAP Password:
dn: cn=Karim OpenDJ,dc=singlepoint66,dc=com
userPassword:: xx
mail: karim@opendj.com
givenName: Karim
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
uid: karim
cn: Karim OpenDJ
sn: OpenDJ
~> ldapsearch -LLL -h 10.210.0.206 -b "dc=singlepoint66,dc=com" -D "CN=directory manager" -W "(uid=karim)" "+"
Enter LDAP Password:
dn: cn=Karim OpenDJ,dc=singlepoint66,dc=com
numSubordinates: 0
structuralObjectClass: inetOrgPerson
etag: xx
pwdPolicySubentry: cn=Default Password Policy,cn=Password Policies,cn=config
subschemaSubentry: cn=schema
hasSubordinates: false
entryDN: cn=karim opendj,dc=singlepoint66,dc=com
entryUUID: xx
pwdChangedTime: 20160930163722.214Z
creatorsName: cn=Directory Manager,cn=Root DNs,cn=config
createTimestamp: 20160930163722Z

You will notice that the uid and sAMAaccountName attributes are the same. So I went ahead and added both as Identity Sources in my SecurID Access Environment:

Then on the LDAP Identity Source I searched for the uid attribute in the page:

Then I clicked on the Pencil under the Mapping column and set the Target Attribute Name to user_id:

Then if you go back to the User Attribute page, you can now search for the new name (user_id):

Then I went to the AD Identity Source and did the same thing for the sAMAccountName attribute:

Now I can use that name under policies and it will show up a valid attribute that you can select. I created a simple policy saying that if user_id is equal to karim, allow access:

Don't forget to choose both of the Identity Sources when adding the policy:

Now if I can assign that policy to an application and if I authenticate with either of the Identity Sources, I will see the application. 

Separate Attributes Names (No Attribute Mapping)

Let's use a similar scenario as above, I have an LDAP server and an AD server. A common attribute between those two servers is mail, you can't change the target name for more than one attribute with a unique name. For example I modified the mail attribute for both identity sources:

But if I try to use those new names only the second one shows up in the list:

If you are in a situation where you have multiple Identity Sources with same attributes and you want to create a policy that applies to only one, then just select the appropriate Identity Source when creating the policy:

 

Filter Blog