when you find the need to go beyond documentation.. IDentity EnAbled Services

1. Password Management: Grief Relief
2. Identity Management Is Here to Stay
3. Moving Beyond Compliance to Business Value
4. Simple Sign-On
5. Ruby Tuesday's Identity Crisis

PS : no time to blog details, and the above list of things were what I thought were worth bloggin on.. and since I had no time to blog (have to catch a flight. gotto rush) I thought that a linked list was a better choice.

tee hee...; Remember my old post on RFID; Here's a new spin to it; tee hee...

In order to conduct a scientific survey of the tiger population this year, Wildlife Institute of India (WII) would soon be issuing photo identity cards to all the tigers of the country. WII scientists have also proposed three new scientific techniques to have a more accurate count of the tigers living in the wild. As per the proposal, the three techniques are namely computerised pugmarks, camera traps and DNA tests. All the three techniques would be used in the tiger survey starting in the country from January 15.

Read More...

REMINDER : Here's a good example of how identity theft can give you nightmares.

In the early 1990's, someone ran amok, using Mr. Lorenzo's identity. It was used to rack up tens of thousands of dollars in fraudulent credit card debt. It was given to the police after various traffic violations. And a man even used the name Raymond Lorenzo when he was arrested and indicted in 1991 in Suffolk County, N.Y., for, among other things, burglary, forgery and criminal possession of a weapon.

Read More...

PS: Identity Management needs to be given importance. More importance than anything else.

After James McGovern, kicked off the discussions around Identity Federation, Pat's response was quite a detail. Johannes Ernst, Shekar Jha, Tom Gordon, Radovan Semančík & Mark Dixon and a lot more chimed in with their perspectives, and I thought that my 2.0 cents on the subject was worth posting.

Identity Bloggers pretend that notions such as Sarbanes Oxley don't exist (or at least never mention them).

Well, I believe that all bloggers who speak on identity management are very well aware of SOX and it's likes. Why in this day and age do we believe that compliance is not critical. I think that it would be foolish to believe that identity bloggers ignore SOX.

SAML 2.0 is a good move to increase interoperability and should be implemented in all security oriented products. Maybe you can tell us why within the enterprise we should use SAML 2.0 between say Active Directory and RACF vs. sticking with tried and true approaches such as Kerberos?

I'd like to re-iterate Pats' comment once again here : You use the appropriate tool for the job. Where there is a tried and true approach then use it. What more could I add to it ??

Do you think that enterprises are well-served by consolidating identity stores vs keeping them spread all over the place and doing SAML?

There was a time period where the entire industry was thinking in terms of consolidating the disparate authentication systems into one huge repository for authentication data. Well, it was not a easy task. Consolidation has it's own pro's and cons. I guess I'm missing out on something here. Consolidation between user identities that are owned by 2 seperate organizations ?? Aint federation the topic of discussion here ? OR is James referring to a "passport" structure ?

If you want corporations to embrace the notion of federated identity, wouldn't it require more than simple "look at me" interoperability demos and for all the vendors in this space to create some publicly available notion of "reference architecture" above and beyond what exists in Project Liberty?

I believe that there was more than just a "look at me" kind of a demo done by Gartner sometime ago. But hey ! I believe that this would be a great opportunity for me to utilize my resources and contacts to put together a real live network of federated systems that use various dispare systems like sxip, netmesh, shibboleth, Sun Federation Manager and throw a live federated infrastructure out there.

How should we think about SmartCards within our own infrastructure and how it plays with federated identity? I know MS is doing this for their own employees.

I'm surprised that James mentioned MS and forgot all about JavaCards. Mary Has one too ;-)

How come pretty much all of the identity bloggers don't support trackback in their blogs? Is it because they haven't yet figured out how to protect their own identity or that of others?

C'Mon James, You didnt need Pat to tell you about trackback spam. Guess we all have a long way to go. But hey !! here's a thought. While we all think in terms of authenticating user identities, we forget that authenticating devices (device identities) is as critical as user identities. IP address and MAC addresses can be spoofed easily. But by embedding a unique security key in a device (something that cannot be spoofed) we could embark on authenticating and authorizing a device prior to letting the device on any network. I liked it when in the good old days, an IP address was granted to a device AFTER the fact that authN was succesful. In todays world regardless of authentication; a device is granted an IP and is placed onto a network. Well, we've made the life of a unauthorized person a lot more easier by letting him in. If we could authenticate and authorize devices prior to granting IP addresses or placing devices on a trusted subnet by using some form of secure key identifier, we'd be closer to being in a more secure environment. I have done some work on this forefront; but poor me, I'm not a sales guy and am having a hard time selling the thought. maybe someday

OK... here's my prediction for the new year and the oncoming... Identity Management would be the CORE for WEB 2.0-The next generation Web. Having said that I thought that it would be good to list out a few open source Identity Management products that are out there that one would need to keep a keen eye on... PS: Do feel free to add to this list by leaving your comments.

• Sun Interoperability Prototype for Liberty : Interoperability Prototype for Liberty is the first open-source implementation of the Liberty Alliance Version 1.0 specification based on Java technology. IPL consists of sample Java source code libraries, implementing the Liberty version 1.0 specification, and is not designed for commercial deployment. IPL is licensed as open source under the Sun Microsystems Open Source License.
• SourceID : Open Source Federated Identity Management Liberty Alliance, SAML, and WS-Federation. Royalty free commercial use if used on fewer than 100 computers per company
• Shibboleth : Shibboleth is developing architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls. Key concepts within Shibboleth include: Federated Administration, Access Control Based On Attributes, Active Management of Privacy and used OpenSAML.
• OpenSAML : OpenSAML is a set of open source Java and C++ libraries that are fully consistent with the SAML 1.0 and 1.1 CR specifications.
• Yale CAS : The Central Authentication Server (CAS) is designed as a standalone web application. It is currently implemented as several Java servlets and runs through a HTTPS server.
• Atlassian Seraph : Seraph is a very simple, pluggable J2EE web application security framework.
• OpenSPML : The toolkit offers an easy-to-use interface for configuring, issuing and interpreting standards-compliant provisioning requests across diverse identity infrastructures.
• Novell Nsure UDDI Server : Nsure is a UDDI 2.0 registry built on Directory Services technology. It offers a secure access to the registry contents (authentication and authorization), unified account management, and distribution of the registry by leveraging Directory Services. It works with any LDAP(V3) based directory backend.
• OpenPrivacy : A reference implementation of the Reputation Management Framework (RMF). OpenPrivacy's core project is designed to ease the process of creating community with reputation enhanced pseudonymous entities. The RMF is primarily a set of four interfaces: Nym Manager, Communications Manager, Storage Manager and Reputation Calculation Engine (RCE).
• NSF Middleware Initiative : NMI-EDIT: Identity and Access Management for Collaborative Applications.
• jSai : jSai (pronounced "Jay-Say") is iPOV's home grown Servlet Authentication Implementation. jSai is implemented completely using J2SE + Servlet technology; no J2EE "Application Server" needed. jSai supports basic JDBC and XML backed user stores, as well as an LDAP user store. jSai provides developers with the application level security they want and need for small and medium size web applications; avoiding the complex setup in other security implementations that are aimed at large "enterprise" applications.
• Acegi Security System for Spring : Comprehensive security services for The Spring Framework.
• Gabriel : Gabriel is a security framework for Java. By using access control lists and permissions, Gabriel enables components to check access to actions. On top of that Gabriel protects methods like EJB does but without the overhead. It distinguishes itself from other frameworks by the ease of use with a small API and by mapping method access to permissions instead of persons. This way the same permissions can be used to protect method access and to check which GUI elements to show based on user permissions.
• JOSSO : JOSSO, or Java Open Single Sign-On, is an open source J2EE-based SSO infrastructure aimed to provide a solution for centralized platform neutral user authentication. The Pluggable framework allows to implement and combine multiple authentication schemes with credential stores.
• Kasai : The goal of Kasai is to provide a simple-to-use-yet-powerful security environment for multi-user applications. Unlike JAAS, Kasai provides a much higher security abstraction. Additionally, Kasai includes a very powerful and performing auditing system that records all users activity on a relational database.
• JPAM : JPAM is a Java-PAM bridge. PAM, or Pluggable Authentication Modules, is a standard security architecture used on Unix, Linux and Mac OS X systems. JPAM permits the use of PAM authentication facilities by Java applications running on those platforms.
• CAS Generic Handler : CAS Generic Handler is a plugin giving CAS (Central Authentication Service) the ability to authenticate users with different methods (LDAP, database, files, NIS, ...).
• SunXACML : This project provides complete support for all the mandatory features of XACML as well as a number of optional features. Specifically, there is full support for parsing both policy and request/response documents, determining applicability of policies, and evaluating requests against policies. All of the standard attribute types, functions, and combining algorithms are supported, and there are APIs for adding new functionality as needed. There are also APIs for writing new retrieval mechanisms used for finding things like policies and attributes.
• Shaj : Shaj (Simple Host Authentication for Java) is a simple library that allows your Java app to verify users with the underlying operating system. Shaj also allows you to check group membership. Shaj is not a competitor for full featured authentication API's but rather a complimentary way to piggyback on system accounts on any platforms. Shaj is used in FishEye for local account authentication, hence it is in use on most flavours of Windows and *NIX.
• Open Web SSO : The Open Web SSO project provides core identity services to facilitate the implementation of transparent single sign on as an infrastructure security component. The goal of Open Web SSO project is to provide an extensible implementation of identity services infrastructure that will facilitate single sign on for web applications hosted on web and application serversThis project is based on the code base of Sun Java(tm) System Access Manager product.
• Cosign : Support Global Logout by visiting a link Support GSSAPI authentication Written in C and support MS ISAPI (IIS), Apache 1.3/2.0, Servlet and Java/J2EE

Links Courtesy: Carlos E. Perez

UPDATE: another comprehensive list at http://safehaus.org/map/nov05.html. Link Courtesy : Shekhar Jha UPDATE 2: Shekar Jha has also compiled a very nice list of Identity & Access Management vendors. boy!! how could I have missed that one ?

Yes !!! Access Manager 7 is coming out. pretty soon... Here's a Sneak Preview...(I Shall Provide More Screenshots AFTER the binaries are publicly released)

• Features & Benefits
• Data Sheet
• FAQ
• ROI Calculator : Macromedia Flash

Whats New ?

1. New Access Manager Console

   The Access Manager Console has been redesigned for this release. If Access Manager is deployed with any of the following products, however, you must install Access Manager in Legacy Mode and use the Access Manager 6 2005Q1 Console:

   • Sun Java System Portal Server
   • Sun Java System Communications Services servers: Messaging Server, Calendar Server, Instant Messaging, or Delegated Administrator

   For more information, see Compatibility Issues.

2. Identity Repository

   An Access Manager identity repository contains information pertinent to identities such as users, groups, and roles. You can create and maintain an identity repository using either Access Manager or another provisioning product such as Sun Java System Identity Manager. An identity repository can reside in either Sun Java System Directory Server or any other LDAP version 3 (LDAP v3) compliant directory server. Access Manager can have read/write access or read-only access to an identity repository.

3. Access Manager Information Tree

   The Access Manager information tree contains information pertinent to system access. Each Access Manager instance creates and maintains a separate information tree in Sun Java System Directory Server. An Access Manager information tree can have any name (suffix). The Access Manager information tree includes realms (and sub-realms, if needed). A realm (or sub-realm) contains configuration information that defines a set of users and/or groups, how users authenticate, which resources users can access, and the information that is available to applications after users are given access to resources. (A realm or sub-realm can also be empty.) For more information, see Access Manager Installation Modes.

4. Session Property Change Notification

   The session property change notification feature enables Access Manager to send a notification to the specific listeners when a change occurs on a specific session property . This feature takes effect when the “Enable Property Change Notifications” attribute is enabled in the Access Manager administrator Console. For example, in a single sign-on (SSO) environment, one Access Manager session can be shared by multiple applications. When a change occurs on a specific session property defined in the “Notification Properties” list, Access Manager sends a notification to all registered listeners.

5. Session Quota Constraints

   The session quota constraints feature allows the Access Manager administrator (amadmin) to set the “Active User Sessions” attribute to limit the maximum number of concurrent sessions allowed for a user. The administrator can set a session quota constraint at the global level for all users or for an entity such as an organization, realm, role, or user that apply only to one or more specific users. By default, session quota constraints are disabled (OFF), but the administrator can enable them by setting the “Enable Quota Constraints” attribute in the Access Manager administrator Console. The administrator can also configure the behavior if a user exhausts the session constraint quota by setting the “Resulting Behavior If Session Quota Exhausted” attribute:

   • DENY_ACCESS. Access Manager rejects the login request for a new session.
   • DESTROY_OLD_SESSION. Access Manager destroys the next expiring session.

   The “Exempt Top-Level Admins From Constraint Checking” attribute specifies whether session constraint quotas apply to the administrators who have the “Top-level Admin Role”.

6. Distributed Authentication

   The distributed authentication service allows user identity and credential collection interaction for the demilitarized zone (DMZ). During authentication to Access Manager, the user must provide user identification and credentials. During this process, the Access Manager service URLs are exposed to the user. You can avoid this exposure by using a proxy server; however, a proxy server is not an acceptable solution for some deployments. Most of the secure deployments do not allow Agents (from the DMZ layer) redirecting the request to the Access Manager server (in secure zone, behind the firewall) directly and hence this is the primary requirement for the Distributed Authentication service. This feature is delivered and deployed as J2EE Web application on any servlet compliant Web container. The Authentication Service can have a remote authentication presentation and extraction framework (that is, distributed authentication UI) that can be deployed as J2EE Web application in the DMZ layer (on a machine not running Access Manager) and which in turn, can communicate with back-end servers for the actual authentication. The Distributed Authentication service communicates to the Authentication server (remotely) for actual authentication via remote API.

7. Multiple Authentication Module Instances Support

   All authentication modules (out of box) are extended to support the sub-schema with Console UI support. Multiple authentication module instances can be created for each module type (module class loaded). For example, for instances with names of ldap1 and ldap2 for an LDAP module type, each instance can point to a different LDAP directory server. Module instances with the same names as their types are supported for backward compatibility. Invocation is server_deploy_uri/UI/Login?module=module-instance-name.

8. Authentication “Named Configuration” or “Chaining” Name Space

   A separate name space is created under an Org/Realm, which is a chain of authentication module instances. The same chain can be reused and assigned to an Org/Realm, Role, or User. The Authentication Service instance equals the Authentication Chain. Invocation is server_deploy_uri/UI/Login?service=authentication-chain-name.

9. Policy Module Enhancements

   Personalization Attributes
   In addition to Rules, Subjects, and Conditions, policies can now have personalization attributes (IDResponseProvider). The policy decision sent to the client from the policy evaluation now includes policy-based response personalization attributes in the applicable policies. Two types of personalization attributes are supported:

   • Static attributes. You define the attribute name and value in the policy.
   • Dynamic attributes. You list the attribute names in the policies, and values are fetched from the Identity Repository data stores at policy evaluation time.

   Policy Enforcement Points (agents) typically forward these attribute values as HTTP Header or Cookies or Request Attributes to the protected application.

   Access Manager 7 2005Q4 does not support custom implementations of the Response Provider interface by customers.

   Session Property Condition
   The session policy condition implementation (SessionPropertyCondition) decides whether a policy is applicable to the request based on values of properties set in a user's Access Manager session. At policy evaluation time, the condition returns “true” only if the user's Access Manager session has every property value defined in the condition. For properties defined with multiple values in the condition, it is sufficient if the user session has at least one value listed for the property in the condition.

   Policy Subject
   The policy subject implementation (AMIdentitySubject) allows you to use entries from the configured Identity Repository as policy subject values.

   Policy Export
   You can export policies in XML format using the amadmin command. The new GetPolices and RealmGetPolicies elements in the amAdmin.dtd file support this feature.

   Policy Status
   A policy now has a status attribute, which can be set to active or inactive. Inactive policies are ignored during policy evaluation.

10. Site Configuration

    The site configuration feature provides simple and centralized configuration management for Access Manager deployments that have multiple Access Manager instances behind a load balancer. Access Manager can be configured in session failover mode, if required for the deployment. To configure the site configuration, use the Access Manager Administrator Console, under Configuration, System Properties, and then Platform.

11. Bulk Federation

    Access Manager 7 2005Q4 provides bulk federation of user accounts to applications that are outsourced to business partners. Previously, federating accounts between a Service Provider (SP) and an Identity Provider (IDP) required each user to access both the SP and IDP sites, create accounts if not already there, and federate the two accounts through a Web link. This process was time consuming. It was not always suitable for a deployment with existing accounts or for a site that acted as an identity provider itself or use one of its partners as an authenticating provider.

12. Logging Enhancements

    Access Manager 7 2005Q4 includes several new logging enhancements:

    • New fields (or columns): The MessageID field contains the message identifier for the logged event. The ContextID field contains the context identifier, which is analogous to a session identifier and applies to all events for a particular user's login session. For a user's specific login session, ContextID will be the same in all log files for logged events.
    • Logging API. The API includes additions for reading log records, including from a database (DB), when logging to DB is configured. Refer to LogReaderSample.java in the /opt/SUNWam/samples/logging directory, which shows the retrieval of log records from a flat file or DB table repository.

For More information See The Docs

Please read Stephen Downes's two part series on "Authentication and Identification" & "Self-Identification the World Wide Web".

The idea behind mIDm : pronounced "My-Dee-Me" is that people using the web can log in once, on their own website, and then forget about logging in anywhere else. It is, in essence, single sign-on for the people.

I had been blogging my woes in this subject arena for a while now. Identity Management surely is a critical component in "todays" technological workspace, but Stephen's post got me thinking again on self-identification. I believed that Identity Federation was the only way forward. However self-identification got me thinking again. Wow !!! we have ways more to go in defining and the term "Identity"

Identity Management, and Identity Federation has been the buzzword in this space for a while now. According to the definition of "Federated Identity" on wikipedia, it has two general meanings:

• The virtual reunion, or assembled identity of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
• The process of a user's authentication across multiple IT systems or even organisations.

now, this is great when the Legal Entity has a unique "identity" on each of the disparate systems. But when the Legal Entity who has a identity on a system is provided access to a partner site or system, there is absolutely no "Federation" possible if the Legal Entity has no identity on the partner site or system. I was involved in a brainstorming session related to shibboleth with a few technical folks from a university. What came up was the need to allow students from one university to access resources from another university. The folks I was interacting with were "sold" on the idea of federation, but lacked complete understanding of how federation really worked. Here were my concerns:

• The user needed to have a unique identity on either systems.
• The user needs to explicitly "federate" his identity. (If he does have a unique identity on each system)
• If the users identity gets stolen, well, we have a much bigger issue.

(I thought) What the university really needed was implicit Federation. Whereby when a user who has authenticated himself at one university, when provided access to resources in another, should be granted access even thought the user does not have a unique identity at the other. Here's an example:

1. University1 and University2 belong to a "defined" Circle of Trust.
2. Student at University1 authenticates at University1.
3. Student tries to access resources at University2.
4. University2 Requests University1 to assert the validity of the user session.
5. University1 Asserts that the user is "A" authenticated user, but does not actually reveal the users "handle" or "identity" in any form
6. University2 grants the user access by just knowing that the user is a "authenticated" user at University1, without even knowing who the user actually is. (University2 provides just generic content to the user)
7. User tries to personalize his "content" or University2 needs to provide the User "specific" content based on role the student has at University1
   • University2 would need to prompt the user for "permissions" to derive his "role" from UnIversity1
   • User grants permissions by using a digital signature of some sort.
   • University2 uses that digital signature to request University1 for the Users roles
   • University1 verifies that the digital signature matches that of the Authenticated User and grants University2 the users roles and/or "identity/alias".
   • University2 provisions a local "identity/alias" and associates it with the "role" as asserted by University1
8. University2 can now allow the user to "personalize "content" or provide the user "content" as necessary.

I believe that with this aproach, even though a student has no "identity" on one system or university (University2 in the example I used) he/She still gets to experience the "magic" of "federation". On second thoughts, If I apply this to the examples widely used in "federation", where a airliner and a car rental company are in a circle of trust, well, I am sure that the car rental company would love to receive a new unidentified user from a "partner airline" and dynamically provision the user and sell him a product !!! it's all about making money in the bargain right ? or is it just making the user experience more enjoyable and easy ? I believe that we'd be kidding ourselves if we say that it's ONLY about "user experience" Now: The user providing his/her "digital signature" to the car rental company is another story altogether.. ;-) Comment Away Please... (Comments are active for only 30 days from the date of this posting) UPDATE : Please Read Pat Patterson's response by Clicking Here or by following the link in the 1st Comment/Trackback below.

Pat Patterson just made me aware that the architecture draft and usecase documents for the opensso project have been published.

The objective of this document is to provide brief and precise information relevant to the high-level architectural goals of core identity services for the web platform. The examples provided in this document are based on the general understanding of web application interactions where the end user interacts with target systems using a traditional web browsing application and follows hyperlinks or other similar constructs. Familiarity with operational aspects of web applications is a prerequisite to understanding the concepts and ideas discussed within this document.

Rush Over, Read the docs as soon as you can, I have been awaiting this for a while now. The part I liked best was section 2.3.2 on Security and Confidentiality. OpenSSO has it's initial miniscule set of limitations though, especially when dealing with "Cross Domains". But hey, the project is at it's infancy right now. I bet Cross Domain SSO (OpenCDsso) would be introduce as participation increases. It's Open Source and it's our participation that makes a product attain it's peak in service provisioning. So go ahead lend a hand. I would love to see opensso handling tickets in addition to cookies/token validation. Hey maybe we could start a opensso branch for extensions. PS: Thanks, Arvind for putting this together so fast.

With this, this, this, & these, conversations going around, I guess it's time for me to layout my meek plans for "n Factor" Authentication. (a step towards strong secure AuthN) Prerequisites :

1. Sun's Java Card Technology
2. Sun's Access Manager
3. Fingerprint Scanner
4. 1024 Bit SSL Certificate
5. Smart Card Reader
6. ...yet to be discovered...

This time around I am only gonna go through an introduction to what I plan to do in order to achieve Secure n Factor AuthN. Details on processes, workflow, implementation methods, and other details will follow in due time... (feel free to join me in the preliminary stages of drafting the architecture at nfactor.org) So here's how the Preliminary Plan Goes... (strawman draft)

• Use the Java Card API to bind a fingerprint (biometric AuthN) to a Certificate stored on a Java Card.
• Use the Java Card API & Java Card Reader SDK, to automatically register the Certificate stored on the Java Card to the device being used (browser for Web Access, and System Registry for Network Access).
• Configure the "device" to authenticate to Sun's Access Manager for Network Access.
• Configure the "web applications" to use the authentication Token validated by Sun's Access Manager for Web Access.
• Build a Authentication Module for Sun's Access Manager to accept the Certificate stored on the Java Card using Access Manager's SDK, The Java Card Readers SDK and the Java Card API.
• Chain Sun Access Managers Default Authentication Module (there's a huge range available) to the custom AuthN Module Built in the prior Step.

  The intention here is to attain "n Factor AuthN". Using a fingerprint to authenticate to the reader in order to obtain access to the certificate store on the java card would be Auth Level 1. The Certificate from the Java Card being presented to Access Manager in order to access the default authentication module would itself be Auth Level 2. The Default Authentication Module (ZKPP) that Access Manager invokes on successul receipt of a user certificate from the Java Card would be Auth Level 3.

  --if youre' still scared of Identity theft, well, one would have to steal your card, cutoff your finger, and then rummage your brains for your userid and password.

  Use Roles, Policies etc... for Authorization and Grant Access to resources (both web, and network) --AuthZ In the next phase, I'd draw up "n factor AuthZ".