I ran across a phrase that reminded me of "the spice must flow" line that rings in the head of any fan of Dune.

enabling the flow of data in such a way as to make its location immaterial

What a great way to describe our recently proposed architecture principle relating to data:

Leveraged Data - Data is an enterprise asset that should be leveraged across the organization over time.

 
The seventh annual Educause Current IT Issues Survey Report highlights two areas which I have been following.  First, Security & Identity Management (IdM) rose to the top, displacing IT Funding as the most strategic issue needing to be resolved for future success.  Second, Portfolio Development & Management was a new category this year and immediately received attention, appearing among the top-ten issues expected to become more significant in the coming year.  Other issues I have been tracking of late were also covered, including ERP, Academic Alignment, and Web Services (SOA). 

Here are some of the highlights from the report, with additional resources referenced at the end.  Overall, this report is a treasure trove of Higher Education IT strategic thinking:

When APU was to deploy our first LDAP directory service, we were looking at running both OpenLDAP and Netscape/iPlanet Directory Server. The sole reason we were going to purchase the iPlanet directory server was because it had a password synchronization mechanism with NT 4. It was a major goal to have a single username and password for all major services running on windows and unix. However, when implementation time came around, we had moved to Windows 2000, which the iPlanet directory did not yet support sychronization with.

Much time has passed...

Identity and Access Management: Technological Implementation of Policy (PDF), provides another great overview of the identity management opportunity. One of the things I appreciated the most about this paper is the clarity of the business case based on "other than IT" perspectives. Besides the amazingly effective Ann West, nsf middleware and nmi-edit outreach coordinator, the article was written by Jeff von Munkwits-Smith, the University Registrar at the University of Connecticut.

A functional definition - Identity and Access Management:

• Integrates all the pertinent information about people from multiple authoritative source systems, reconciles the accounts, and joins identities together under one campus unique identity.
• Processes and transforms information about people including their affiliations with the institution, resource access etc. and pushes out and stores the information where it can be of use to applications.
• Acts as a focus for implementation of policy concerning visibility and privacy of identity information and entitlement policies across the systems.

Some more take-away notes and highlights below...

In Firefox, I have been storing urls to interesting things in a "to blog" folder on my bookmark bar. The hope is always, this would be good to analyze and post about later, but I don't have the time right now. The truth is, they rarely get revisited. So in the interest of sharing, and putting stuff in place more accessible, I will start quick linking.

Found some good Identity Management related resources. Digital ID World online and in print magazine. Interesting Digital Identity Predictions for 2004, in which are mentioned The Laws of Identity, an ongoing discussion to develop the nature of identity in light of desired federation and interoperability. These discussions resulting in the realization of said laws, was initated by Kim Cameron. Which as Doc Searl pointed out, is interesting because Kim Cameron is in charge of Microsoft's Identity Strategy. A good thing that there is a turn from a monolithic identity infrastructure, previously posed by Microsoft, to one that is distributed and diverse, as stated in the Fifth Law of Identity.

In article on Digital ID World, The Great Directory Heresy, Dave Nesbitt asks whether the rising notion that you can throw more metadirectories or suites and federations at bad data end up with a great enterprise directory is heresy. Its like putting lipstick on a pig he says.

Its a great question. Do you cleanse the data you have? Do you make sure you have the perfect directory structure? Or do you forge forward with policy and business logic to populate and push data out to where it needs to go with what you've already got? Will it lead to chaos? Or, as some suggest, is the IdM an interative process, where the idea is more important than one implementation? I do know that its quite easy to end up doing nothing, waiting for the perfect thing.

Clever slogan in the title of a recent article, Authentication - The Power of Who from Campus-Technology Magazine.

Identity Management is all about an organization knowing who its constituents are. I thought the article was a bit random, and incorrectly labeled as all about "athentication" since authorization and provisioning topics are covered. However, it is a good overview of several of the approaches that schools are taking to meet the opportunity. So from a case study perspective its worth a read...

I have posted the Identity Management Roadmap, which is an attempt to break down the broader Identity Management initiative into projects which could be achieved if given appropriate focus and resources over the next year or so. These tasks represent our success in implementing more of the Identity Management Architecture in order to provide APU with complete identity lifecycle management. You'll notice that in order to be successful both business process and technical issues need to be addressed. The overlap of boxes represents the concurrent nature of the tasks, with progress being made on infrastructure while policy and workflow are being refined. This concurrence can be seen in NSF Middleware Initiatives's Enterprise Directory Implementation Roadmap. The breakdown is not only based on concurrence but also considers that each of these projects would be handled by slightly different teams with distributed project leadership. I think that this approach would be more successful than a single large monolithic multi-phased project. There will of course need to be coordination between projects, with overall leadership provided by an iniative sponsor. I would love feedback on this roadmap so that we can procede to write project requests for each of these areas. The future of IMT's ability to deliver transformational self-service as outlined in the IMT Strategic Priorities, is dependent on APU's facilities to manage identity.

Identity Management Roadmap is a divide and conquer approach to the IdM Initiative.

Background

It is increasingly important that identifiers be made coherent and consistent throughout the enterprise. Many systems use different names for the primary identifier used along with a password to authenticate access to a resource (Login, Logon, Username, Name, UserID etc.). When APU started providing central authentication services, which coincided with the release of the üdeupa portal, we established "üdeupa username and password" as the name of this identifier. With the portal name change, we realize that we need a way to refer to an APU Network Account independent from a particular service. For this reason, as well a desire to adopt higher education standards, we are renaming these identifiers.

Summary

The Central Authentication Service requires an APU Network Account consisting of an APU NetID & Password to verify identity. Any system which makes use of the APU Central Authentication Service, should use "APU Network Account" to refer to the account. "APU NetID" should be used to describe the principle identifier. "APU Network Password" is used to refer to the password explicity if needed. Systems that have the capability of modifying the prompting for these identifiers, should be changed. Over time, all user documentation and communication should be updated as well. We should no longer refer to "Windows Login, or "APU Domain Login", but should use the term "APU NetID".

Change Matrix

Old Title	New Title
üdeupa Account	APU Network Account
üdeupa Username	APU NetID
üdeupa Password	APU Network Password
üdeupa Username & Password	APU NetID & Password

Use Cases

1. Centrally Authenticated Services:

   Any service which authenticates against APU Central Authentication Services should state that the service requires an "APU Network Account. Alternately, "APU NetID" may be used to specify the credentials required for a particular service. If password is not explicity stated, APU Network Password is implied by association.

   This service requires an APU Network Account.
   
   or 
   
   Anyone with an APU NetID may use this service.
   

2. Referring to the APU Network Credentials together:

   APU NetID & Password
   
   or
   
   APU NetID and Password
   

3. Referring to the APU Network Credentials explicitly:

   APU NetID
   APU Network Password
   

4. On Login Screens:

   APU NetID: ______________  Password:  ______________
   
   or
   
   APU NetID: ______________
    Password: ______________
   

5. Non-Centrally Authenticated Services:

   Systems which do not authenticate against the APU Central Authentication Service, should refer to their credentials by the name of their system. Example:

   IFAS Username and IFAS Password
   

   Even if a system's initial username has the same value as the APU NetID, it should not continue to be referred to as APU NetID. Equivalent value is not equivalent title. For example: If a user was activating their account a new system which pre-populated usernames to match APU NetID, they could include the following instructions on first login: "Your IFAS Username is the same as your APU NetID, please select a password." Future logins however, should prompt for "IFAS Username" not "APU NetID". Once exception to this, is a service which may require an APU NetID, but not prompt for a password. Such a service, can continue to prompt for APU NetID. (current example: Link+ Library Loan Service)

Notes

The APU Central Authentication Service does not exclusively refer to our implementation of Yale's CAS, an Open Source application for web authentication. APU CAS refers to the centralized authentication services provided by IMT in order to verify identity of users of primary network resources, portal and workstation access etc. APU CAS is supported by IMT's Identity Management infrastructure, consisting of Microsoft's Active Directory and OpenLDAP.

The following Identity Management Model, by Tom Barton, generally shows how identity information should be extracted from source systems (ERP etc.), transformed by metadirectory processes, and loaded into directories for use by consumer systems. This flow can generally be seen from left to right. The magic happens in the often misunderstood Enterprise Directory Services, which is not a single product or LDAP directory, but rather a set of tools which handle the flow of information. Metadirectory processes often provision information services based on unique business rules which define elements of authentication and authorization, and are the primary place where identity resolution occurs between disparate systems.

It is generally promoted to use a relational database to maintain a person registry completely independent from any ERP or vendor application. This "middle database" of sorts, allows the organization to main complete lifecycle control, through custom business process, of one of its most important assets, the identity of its constituents. Most applications with user directories or databases are in constant flux, with accounts being added and deleted based on current state. The person registry allows for a permanent location enabling seemless lifecycle management regardless of software and infrastructure changes.

This architecture, is explained in more detail in the Core Middleware Overview Presentation.