Posts Tagged ‘SailPoint’

Best Practice Role Management Methodologies

Tuesday, July 26th, 2011

When developing Roles within an organization it is important to pre-select the proper Role Management Methodology for use on your project and for ongoing operations once your roles are ready to go live.  There are two approaches that can be used when developing access roles for a company or organization:

  • Top down – With this approach uses a pre-defined method of organizing user access based upon known or developed plan.  An example of this would be: defining user access based upon job function and what access that job requires as the method of organizing people into roles.
  • Bottom up -  With this approach you examine what access people currently have and assign roles based upon what rights those users have. An example of this would be: discovering what rights all (or a group) people have and selecting common access rights for the role being developed.

Both of these approaches have merits and drawbacks associated with their use such:

  • Top down

+  Most effective and comprehensive method of role development

+  Aligns access rights and compliance to business goals regarding compliance

-  Requires business and organizational understanding of access rights at the site

-  Requires significant time in role development before implementation

-  Often difficult to quantify all role assignments and proper access

-  Complexity often leads failure role development or “stuck in the weeds”

  • Bottom up

Quick role development

-  Highly difficult to quantify specific access rights for the roles developed

-  Requires access and mining of specific access data

-  Difficult to align business objectives and compliance with developed roles

It is has been my experience that using a hybrid approach using the following methodology will make a role discovery project successful:

  • Top + Bottom Role discovery – This method uses one or more business or organizational top down role methods and follows with a bottom up approach for discovery and verification.  An example of this would be: take employees job codes as the basis for role creation and locate the access rights associated with the job codes.  Use manual or campaign determination of proper access rights for the roles developed.
  • 80 / 20 Rule - The goal should not be to develop roles for every person at the company or organization.  The goal is provide the most role value by locating access right combinations that cover the majority of individuals.  Implement these effective roles quickly.  Address the exception or difficult to quantify roles later (or when possible).  For example: CEO is not a role, it is a unique job function or more accurately an “exception role”.
  • Phased approach – It has been my experience that role implementation encompassing the entire organization often fails due to the time and complexity required to complete.  Political and/or procedural roadblocks appear, addition of access endpoints and role function or purpose questions occur.  You should implement roles across focused areas of the company or organization where goals are well understood and attainable.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Provisioning to Active Directory with SailPoint (using SSL)

Tuesday, March 22nd, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

SailPoint’s new provisioning engine allows you to create, modify, and delete user accounts on various applications in conjunction with the Lifecycle Request Manager component of SailPoint.  The actual provisioning is done using the Tivoli Directory Integrator (TDI) product.

Provisioning to most applications is a relatively simple setup that consists of developing or importing the Connector and Assemblyline code and modifying the connection parameters to point to the correct application for the given environment.  SailPoint then calls the provisioning plan, which sends a JSON command to TDI which in turn provisions the account.

Provisioning to Active Directory (AD) is a little more complicated.  To create an active AD user with a password, TDI must connect to AD using SSL.  The setup to configure TDI to provision using SSL for AD is below.

Note: The instructions are written for a Windows 2008 server but would be similar if TDI were installed on another platform.

Prerequisites: A working TDI install with the Active Directory AssemblyLine and Connector imported.  These files can be obtained from SailPoint or can be custom written.

  1. Retrieve the CA certificate for the Domain controller
  2. On the TDI server, create or find a folder for the certificate and keystore (ex. D:\TDI_Store)
  3. Copy the CA Certificate to that folder
  4. Open a command prompt and navigate to the following %TDI Install DIR%\V7.0\jvm\jre\bin folder.
    • Example path: C:\Program Files\ibm\TDI\V7.0\jvm\jre\bin
  5. Enter the following command to create a keystore and import the AD certificate:
    • keytool –import  –file “D:\TDI_Store\myservercert.cer”
      –keystore “D:\TDI_Store\keystore.jks” –storepass Password1 –alias TDI_CA
  6. When prompted to trust the certificate, type yes and hit enter
  7. Verify the keystore was created and the certificate was imported by entering the following command:
    • keytool –list –keystore “D:\TDI_Store\keystore.jks” –storepass Password1
  8. Export the default key from TDI by entering the following command:
    • keytool –export –alias server –file tdiServerApi.cer
      –keystore “C:\Users\admin\Documents\TDI\testserver.jks”
    • Note: The path to the testserver.jks corresponds to the user who setup the TDI server and create the server instance in TDI
  9. Enter the following command to import the TDI certificate:
    • keytool –import  –file “D:\TDI_Store\testServerApi.cer”
      –keystore “D:\TDI_Store\keystore.jks”
      -storepass Password1 –alias TDI_CA_Default
  10. Edit the %TDI Install DIR%\V7.0\etc\global.properties file and change the items marked in red.
    1. ## server authentication
      javax.net.ssl.trustStore=D:\TDI_Store\keystore.jks
      {protect}-javax.net.ssl.trustStorePassword= Password1
      javax.net.ssl.trustStoreType=jks 

      ## client authentication
      javax.net.ssl.keyStore=D:\TDI_Store\keystore.jks
      {protect}-javax.net.ssl.keyStorePassword=Password1
      javax.net.ssl.keyStoreType=jks

    2. Example path: C:\Program Files\ibm\TDI\V7.0\etc\global.properties file
  11. Edit the %TDI Install DIR%\V7.0\etc\solutions.properties file and change the items marked in red.
    • # server authentication
      javax.net.ssl.trustStore=D:\TDI_Store\keystore.jks
      {protect}-javax.net.ssl.trustStorePassword= Password1
      javax.net.ssl.trustStoreType=jks
  12. Restart the TDI Configuration Editor
  13. Open the ActiveDirectory Connector
  14. Under the connection tab, change the following settings marked in red:
    • LDAP URL: ldap://mydomain.com:636
      Use SSL: Checked
      Auto Map AD Password: Checked
  15. Open the ActiveDirectory Assemblyline
  16. Make sure the userAccountControl field is being set to 512
  17. Restart the TDI server

Once this setup is complete, the environment is ready to provision to Active Directory using SSL.

State of the Union

Saturday, October 9th, 2010

Last week Oracle announced they had purchased Passlogix (best known for the V-GO ESSO application) and this got me thinking about the changes in the last 10 years in the Identity Industry.

A decade ago you had start-ups galore.  Business Layers (eProvisioning), Netegrity (SiteMinder), Access360, Thor (Xellerate), Waveset, Oblix, Trulogica, M-Tech and Courion, too name a few, almost all of which were acquired.

Business Layers got acquired by Netegrity who got subsequently acquired by CA.  Access360 got acquired by IBM as part of the Tivoli Identity Manager product.  Thor got acquired by Oracle, Waveset by Sun and subsequently Oracle, Oblix by Oracle as well (I am sensing a trend here by the way).  Trulogica got acquired by HP where it saw its demise.  M-Tech became Hitachi and Courion bucked the trend and stayed Courion.  Even the smaller space tools like Maxware got picked up by SAP.  In fact, up until the last few years, we have remained in the land of the Big Company Identity Stack.

So how did we get there?

Back in the day IDM was slowly being looked at as the next wave in Risk and security.  The issue at the time was that the products were very green and lacked the technical maturity to make implementation a worthwhile process.  Sure, the low hanging fruit of automagically creating an Active Directory or Netware account was a breeze but the implementation around single sign-on, strategic workflows and approval/escalation to a host of applications was not a smooth process.  In fact in the early 2000s the process involved prior to the technology was still being ironed out.  Many of the projects we worked on required a high level of customization and as a result the time to implement took in some cases years to complete.  During these multi-year engagements a good number of projects failed to get off the ground or changed scope so many times that in the end the effort was deemed a failure or not what is was originally sold as.

Eventually sanity won out and most organizations realized that Web Access Management, Provisioning and further more Federation and Role Management were separate sides of the Identity Management box.  Instead of one large “Big Bang” a step by step approach gained traction as a method to actual success.  Many of the larger organizations even split Access Management and Identity Management into strongly separate buckets with their own teams and infrastructure.  Gone are the days where Access Manager and Identity Manager are viewed as the same application.  Today the products are treated as interconnected but individual pieces complimenting each other even when they fall into the same stack.  This can be seen in the job reqs that many organizations release when looking for a technical resource.  5 years back recruiters were still looking for the Jack-of-All trades Engineer/Developer/Architect/PM that knew the SSO, Provisioning, Federation, Role Management and Password Management tools from the 4 different vendors (my personal favorite being when the recruiter would then say a “junior” resource for said position was OK as a method to justify the sub-par rate, as if such a “junior” person existed with that level of knowledge).

The big company buy-up of the old Venture Capital backed firms yielded a greater maturity in the market and a fierce rivalry in the market place.  In fact the biggest players are now Oracle, IBM, CA, Novell, and to a lesser extent BMC and a hard charging Microsoft.  What is interesting though is as of a few years back the next generation of VC based IAM start-ups popped up and we are seeing history repeat itself with the next wave of industry consolidation.

For instance, take a look at the Role Management and Identity Governance market place.

Bridgestream Roles and Vaau RBACx got scooped up by Oracle and Sun and subsequently Vaau won the application war as Oracle’s preferred Role application (under the unfortunately named Identity Analytics banner).

Aveksa and Sailpoint popped up to not only compete in the same space but to offer superior products to manage compliance with HIPAA, SarBox and the like moving beyond solely role management into the governance and compliance management space.

Eventually, as is the case in the IAM space one, one or both companies are likely to be acquired.  Where they will land is open to conjecture but like all Venture Capital based opportunities you are either a resounding success in the sales game or you are a cheap acquisition target.  I have my own guesses as to what comes next for both companies but alas that is a topic for another blog entry.

As for the announcement of Passlogix being acquired, Oracle has a strong set of tools in the space covering all facets of Identity and Access Management.  They are truly becoming the Walmart of the Identity World.

The truth about Roles, what people won’t tell you about RBAC

Monday, August 2nd, 2010

I have been at three separate companies as of late  that all strive to have the “perfect role model” for their enterprise. This desire is usually coupled with the desire to have some irrational number of roles to show that their role model was successful.

<Sidebar> Let’s say your company has 100,000 people worldwide, how on earth could you believe that you’re going to end up with 10 roles?

The answer to the number of roles is generally a product of how you want to create enterprise roles (this includes Business and/or IT roles). There are few options when it comes to designing roles, to list a few:

  1. Bottom-up, Top-down and Intersection Analysis (yawn, that’s so 2009)… and the result being a set of IT roles that map to resources, and business roles that map to the IT roles.
  2. Allow Supervisors to control # of roles, they decide what goes in their roles, and your systems make sure that they haven’t put any “toxic combinations” in their roles.
  3. Use #1 & #2 with a standard set of entitlements that everybody gets based on some organizational data.
  4. Allow a product to analyze your data and suggest candidate roles.

(All of these mean nothing unless your roles are “in-context”… to be covered in my next post.)

Now comes the part where I give my prescriptive advice on which of the 4 options to use. The answer: RBAC is art, not science, you should try all of the above, at least see if they pass the litmus test for your organization (better yet, call IDMWorks and we can help you figure it out).

Once you’ve figured out what direction you are going with roles, the next step is to stuff all of that in a product. Might I suggest Aveksa as it is the one of the best products in the industry, and use it to manage your roles, entitlements, segregation of duties rules and certifications.

Do I really need Role Management? Yes you do (aka I pity the fool that don’t have Role Management)!

Friday, June 11th, 2010

Enterprise role management is a critical technology for allowing organizations to verify and enforce regulatory mandates and to audit the effectiveness of user access policies. Role management facilitates business and IT policy alignment by helping you translate business policy into technical IT controls such as separation-of-duty rules. With reporting and identity analytics capabilities, you have easy access to a variety of audit data and compliance metrics.

Role management is a critical component in addressing governance and compliance requirements for user access to mission-critical applications and data. Roles support compliance by aligning access privileges to user job functions within the organization and by providing business context to lower-level entitlements and permissions, which need to be reviewed by business managers and compliance staff.

Role lifecycle management must let you create, enforce, and verify role-based access across enterprise applications. Aggregating user access privileges under roles lets you improve entitlement management and ensure that access rights adhere to business and regulatory policies. Ensuring adherence to these policies requires that business managers and auditors review and certify that user access privileges are appropriate within the organization. Role Management should enable you to identify policy violations and inappropriate access and take corrective actions when necessary.

Configuring Identity Attributes in SailPoint IIQ

Friday, May 28th, 2010

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

What are Identity Attributes and how are they used?

Identity Attributes are essential to a functional SailPoint IIQ installation.  SailPoint IIQ represents users by Identity Cubes.  Identity Cubes are a correlated collection of accounts and entitlements that represent a single user in the real world.  Identity Attributes are used to describe Identity Cubes and by proxy describe the real-world user.  Identity Attributes are created by directly mapping a list of attributes from various sources or derived through rules or mappings.

Take first name and last name as an example.  First name is references in almost every application, but the Identity Cube can only have 1 first name.  To make sure that identity cubes have an assigned first name, a hierarchical-data map is created to assign the Identity Attribute.  When refreshing the Identity Cubes, IIQ will look for the first matching value in the map and use that as the Identity attribute.  The hierarchy may look like the following: If firstname exist in PeopleSoft use that.  If not, then use the givenName in Active Directory.  If that doesn’t exist, use the first name in LDAP. Etc.

How are Identity Attributes Assigned?

Identity Attributes are setup through the Identity IQ interface. To add Identity Attributes, do the following:

  1. Log into SailPoint Identity IQ as an admin
  2. Click on System Setup > Identity Mappings
  3. Click New Identity Attribute
  4. Enter the attribute name and displayname for the Attribute

Note: The attribute name is used to reference the identity attribute in forms and rules, while the displayname is the value shown to the user in the UI.

  1. Click on Add Value Map
  2. Select the appropriate application and attribute and click OK
  3. Repeat step 6 for all mapped attributes
  4. Select any desired options (Searchable, Group Factory, etc.)
  5. Click OK

After adding identity attributes, populate the identity cubes by running the Refresh Identity Cubes task.

Added Identity Attributes will not show up in the main page of the Identity Cube unless the attribute is populated and they UI settings have been changed.  To enable custom Identity Attributes, do the following:

  1. Log into SailPoint Identity IQ as an admin
  2. Navigate to the debug interface (http://www.yourcompany.com/iiq/debug)
  3. Click on the UI Config button
  4. Modify the following entry:
    <entry key=”identityViewAttributes” value=”name,firstname,lastname,email,manager,employeeid “/>
  5. Click Save
  6. Restart the application server

After restarting the application server, the custom Identity Attributes should be visible in the identity cube.

Questions? Ask away at IDMWorks!