A Need for Standards

I came across an interesting eWeek Blog entry.  In it, Michael Vizard makes some interesting points about lack of standards in Identity Management. He makes some valid points in that there is no real standard for creating physical means proving identity. While a comprehensive framework makes sense for physical provisioning and Access Management, I have some concerns.  If we have a published framework for creating Access Management tokens, that makes it that much easier to compromise those standards.

Mitigating this concern is the fact that there are several ways to ensure the validity of the issued token.  The FIPS standard cited in the blog entry makes heavy use of PKI technologies.  I would assume other hashed attributes would be a part of the token as well.

My other primary concern is that the examples that Vizard cites are both governmental in nature.  It would make much more sense to me if there was a public sector standard cited as well.

It will be interesting to see how this develops in both the public and private sectors.

Project Scope and Sustainability

(This post was written by Matt Pollicove)

One thing I’ve noticed when talking to people about Identity Management projects involves how to determine the project’s overall scope.  “How do I scope this?” they will say to me.  Now that’s kind of tough to answer right off the cuff, especially when considering Pollicove’s Law of Provisioning  which basically says there’s no guarantee that companies that are in the same vertical will work the same way.

 

However, I think there are some best practices that can be worked with when considering implementing an Identity Management solution:

 

1.       Make sure you have executive sponsorship.  C-level support is going to be important in balancing the needs of your stakeholders and their budget dollars.

2.       Make sure you have a good plan of what you want your Identity Management solution to cover.   An essential part of this is conducting a thorough assessment.  Document everything, diagram existing processes, then take them apart and put them back together the way they should be, then do it again.  This should be done with a combination of internal and external sources.  Internal resources know how current systems are configured and interact.  External resources will offer an impartial assessment of how these systems can interact more efficiently. External resources will also be helpful in determining which Identity Management products will work best in your infrastructure.

3.       When building your plan, know where you’re starting from.  What will be used as your authoritative store?  How will it be built?

4.       Where are you going to? What will you provision to?  What will you control access to?

5.       How are you going from 2 to 3?  How will you engineer your changes?  What will the phases of your project consist of?

 

Item 4 is probably the most important part of the process.  Many a project has suffered due to overreaching phase objectives. Carefully define what you want to achieve in each phase. 

 

Data cleansing and analysis is almost always your first phase.  If you don’t have clean data, you won’t have a clean project.  Future phases can deal with:

·         Creating an Authoritative Store

·         Provisioning to essential systems

·         Password management

·         Role management

·         Provisioning to secondary systems

·         Etc.

 

So the big question is what order does this happen in?  How long will it take?  I always suggest attacking “low hanging fruit” first by attacking the easiest objectives that will show the biggest net gain?  As a part of number 1 above, think about solving automation needs, compliance needs, addressing password management request costs to the helpdesk? 

 

How long will it take?  As long as it has to.  This is going to be a major project that will affect many systems and departments.  Take it slow and easy.  Test it thoroughly and make sure there’s a good knowledge management/training initiative to let your users know what happening and how everyone will benefit.  It’s never good if your users equate an Identity Management initiative with a foul tasting medicine.  This includes your stakeholders.

More Thoughts on Federated Provisioning

If we look up the definition of the term “federated” in the Computer Desktop Encyclopedia via answers.com it returns this definition:

“Connected and treated as one. See federated database and federated directories.”

This definition makes sense when we discuss identity.  We have two systems within separate legal entities separated by a barrier.  At one time this barrier was  like a wall, a fortress.  Entry was made through prescribed gates.  Today it is more like a cell with it’s bi-layer lipid membrane and  trans-membrane proteins.  It acts as a protective barrier and a regulator of transports in and out.  When we connect the IdM system of one entity with another they are treated as one; however, the other sub-system elements are logically subordinate so if we talk about federated provisioning there is a strong argument that it is semantically irrelevant.  Ian Glazer is right there is only provisioning.

Identity Management 2.0

I saw an interesting article that discusses the concept of Identity Management 2.0.

The article starts with a good recap of current, or Identity Management 1.0 capabilities, that we are all familiar with, access management, LDAP, Provisioning, etc.

Where the article gets really interesting, of course is when the Author delves into what he considers to be the revolution of Identity Management.  As the article states:

The core platform of Identity Management 1.0 capabilities such as authentication, authorization, user provisioning, password management and the like has provided a base for improving security and automating manual processes to drive down operational costs. Identity Management 2.0 extends the core platform to offer stronger forms of authentication, risk-based authorization and fine-grained entitlements, user provisioning based on roles and relationships, as well as the ability to virtualize identities, all in an effort to address the next generation of requirements and threats.

What, to me, is even more interesting is that an old IdM technology, Virtual Directory, is considered to be a core component of IdM 2.0.  Dubbed “Identity Virtualization,” the article likes using this technology for creating customized user repositories for applications. Maybe the oft-quoted “Year of the Virtual Directory” is finally coming to pass.

It should be interesting to see how this concept matures over the next 12-18 months, particularly as we’re going into what many consider to be tight times in the IT world.

Thoughts on the Use of the Term “Stateless Identity”

Gerry Gebel at the Burton Blog has a post titled Can Applications Become Identity-Stateless.  He points out the costs of user provisioning are high and that enterprises would be better served if it could be done away with.  He goes on to say the following:  “For several years, the industry has promoted the use of shared infrastructure services for IdM functions – but only a moderate level of success has been achieved when compared to the potential.”  He then floats the term “stateless-identity” as a possibly better “descriptor” to communicate the desired end state, viz., applications which keep no state on identity and instead share a common store.  The rhetorical question that follows is it in fact a better term?  Consider the concept of ‘stateless’ in software.  When state is not maintained, the software does not keep track of current data, for example, user choices, configuration settings or executed transactions.  When software is stateless it lives in an eternal present, ignorant of what came before and ignorant of what follows.  It carries nothing with on moment to the next.   If we apply this concept, then the meaning which follows from applications using stateless-identity would be applications whose “awareness” of identity is limited only to the current call to the identity service.  Metaphorically, it would be like a man who every time he leaves the room and returns must look up the name of his guest.  Obviously this not what he has in mind because applications must keep persistent information about who is using the application and what they are entitled to do and what limitations they have.  Even if the application is not storing this permanently, it must maintain the state for it’s own functioning and hence stateless-identity lacks descriptive power at best and at worst may cause confusion of the term’s actual meaning such as what occurred in the database world with “relational”.  I understand the goal which is to remove redundant identity data from applications and lower costs, however,  creating new terminology  is a questionable choice when other terms which possess greater descriptive accuracy already exist and are widely known.  I can’t see where this adds any additional communicative power that would speed adoption, but I have been wrong before.

Whitepaper Download

For those of you looking to download a copy of Strategies for Creating an Authoritative Store, it is now available from the SECUDE Global Consulting website.  The paper was initially released through Business Trends Quarterly.

The paper is intended to be a discussion of creating an Authoritative Store for use in an Identity Management Infrastructure.  It provides a good starting point for those considering implementing or revising their IdM landscape.

Useful NW IDM Functions

Recently I needed to do two types of lookups for the prototype of a user creation script.  I was able to do both lookups rather easily using the uSelect function.  This is a function that is often overlooked, but one that really lets a NetWeaver IDM developer get the most out of the Identity Store.

First off, I needed to do a lookup against a “blacklist” of illegal ID’s  I was able to create a small table in the Identity Store database, gave it proper rights and then execute the following JavaScript code:

// First -- Check if AlphaPart is in the BlackList, if EvalBlackList > 0 then it's no good
// This means the item was found in the Blacklist
var BlackListQuery = "SELECT COUNT(*) FROM _Blacklist WHERE (BannedWord = " + "'" + AlphaPart +"')";
var EvalBlackList = parseInt(UserFunc.uSelect(BlackListQuery)); 
 
// if the current AlphaPart is in the Blacklist
if (EvalBlackList != 0){
...

Basically a query string needed to be constructed and then evaluated by uSelect.  The easiest way to check for a conflict is to use a SELECT COUNT type of query of the “Alphalist” variable against the Blacklist table.  If there is a value greater than 0, we have a conflict.  I then needed to do another query where I had to make sure that the new MSKEYVALUE did not conflict with existing values.  The same technique is used except this time we are going up against a view in the Identity Manager database

// Check if this value exists as an MSKEYVALUE
// NOTE IDENTITY STORE VALUE MUST BE HARD CODED!  NW IDM will not allow IDS Loopup via uGetIDStore outside of action tasks.
var IDSNumb = "1";
var MSKEYQuery = "SELECT COUNT(MSKEY)FROM MXIV_SENTRIES WHERE (IS_ID =" + IDSNumb + ") AND (AttrName = '" + "MSKEYVALUE" + "') AND (SearchValue LIKE '" + NewKey +"')";
var EvalMSKEY = parseInt(UserFunc.uSelect(MSKEYQuery));
This query was a little bit different as it needed some more elements involved.  First off, we need to hard code the Identity Store value.  There seems to be an issue with uGetIDStore if it is used outside of an action task.  I will be following up on this with folks at SAP.

// if the current NewKey is in the Identity Store
if (EvalMSKEY != 0){
…

Next interesting thing to note is that the query runs off of the MXIV_SENTRIES view. One might think that MXIV_ENTRIES would be the logical place to start, but it links into a lot of other tables, particularly audit tables which would slow up the script to an unacceptable degree.

I hope these techniques are useful to other NW IDM scripters out there.  My thanks to those engineers both in and out of SECUDE Global Consulting who helped out on this.  I’d be interested in seeing other people’s views on this issue and other scripting issues.

Useful SAP NetWeaver Identity Manager Documentation

Here’s a link to a great document on the Identity Manager Schema.

I’m looking forward to seeing more of this type of documentation from the NW IDM Development team.  This is a great listing of Entry Type definitions, attribute listings and ABAP mappings.

I’m looking forward to also seeing a document that discusses useful stored procedures and table descriptions as well, but this is a great start. 

 

 

New Whitepaper

The Identity and Access Management team here at SECUDE Global Consulting has created a new White paper called “Strategies for Creating an Authoritative Store”.  The paper is currently being hosted on the Business Trends Quarterly site and will be on our corporate website soon as well.

From the White paper:

Creation of an Authoritative Store is a key component of an Identity Management Infrastructure. The Authoritative Store can be created using a number of different strategies. The determination of the best strategy is by a thorough analysis of sources, database resources, available data synchronization tools and the IAM tools in use by the organization.

In the meantime if you would like to read the paper, please email me at (matthew dot pollicove (at) secude-consulting dot com) or register (it’s free!) on BTQ’s website where you can get more information on BI, GRC and other important technology areas.

I will post an update as soon as the paper is available on the corporate website.

Javascript Validation of an Attribute Entry

This came up on the SAP NetWeaver Identity Management forum and since I had to take the screen shots anyway I thought I would show it step by step. In this scenario we are creating a new contractor and we want to set the validation attribute such that it’s maximum value is not greater than one year from today.  I am assuming that one already knows how to create basic workflows.

1. First we open the attribute MX_VALIDTO and click on the Validation tab.

Validation Tab

2.  We are going to use Client-side script. Click edit and it shows an example in a format we must follow so PHP can evaluate it properly.

Client-side script example

3.  Next we enter the JavaScript (originally written by Scott) that will check the validity  of entered date.  The  date is passed in from the workflow as yyyy-mm-dd. Because javascript counts months starting at 0 we subtract 1 from our month value (line 5).  If the date entered is less than the maximum permissible date, the date is returned.  If it is more, we return an error message.  Later this script will be set as a string value called myscript in PHP and evaluated.

JavaScript Validation Code

PHP code in Workflow

4.  Next we set up our workflow and choose our attributes by creating an unordered task which creates a new entry of the MX_PERSON entry type.  Access Control is set to logged in users.

Unordered Task

Attributes

5.  Next we test in our validation in the workflow Create Contractor and enter in the values, including an improper “valid to” date.

Create Contractor Workflow

6.  Click OK and receive error message.

Error Message