our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

Despite your best efforts to contain user IDs and access issues, the user community is bent on complicating your life by requiring support for more external users than internal users, and you have no real control over these users. You'll need to manage these systems as they come along, but without a consolidated plan, your management issues will exceed any reasonable budget. In my endless searches, I've discovered only one approach that's got this down pat. Unfortunately, it's neither simple nor elegant: X.509 attribute certificates coupled with enterprise OIDs (object identifiers) directly address distributed identities and functional roles.

The Application of Public Key Infrastructure The most widely recognized purpose for a PKI (public key infrastructure) is to produce a distributed, highly scalable identity database. What is widely unknown in the corporate world is that X.509 version 3 added attribute and attribute delegation certificates. With attribute delegation certificates,a unique place in the PKI is established to define users' roles and access rights, which are independent of the users' identities and their systems. These certificates are linked to the user authentication certificates. The benefit of this approach is that it lets the authentication certificates be stable; all they do is identify the party. The attribute certificate can be short-lived and can handle the roles and rights of the user. Given such an object, applications can leverage the PKI instead of maintaining their own access lists.

This model represents a major enhancement over traditional user-group access-control databases. The building block for this--frequently called an enterprise OID--is built up from the owning company's OID with detail that reflects the application or group, and perhaps some specific data or field designator. An attribute certificate with such an enterprise OID asserts that the owner of the linked user certificate has the access rights defined by the enterprise OID.

OIDs work similarly to DNS: a level is delegated to a responsible party that can then create a subtree of any depth or breadth under the OID. Your company may already have an OID, or even multiple OIDs issued to it from some authority, such as IANA (Internet Address Naming Authority), WIPO (World Intellectual Property Organization) and UN/EDIFACT (United Nations/Electronic Data Interchange For Administration, Commerce and Transport). You can then set up any structure outward on this OID for your access lists. Only the server side needs to know how to retrieve the attribute certificates; the client side need only be able to supply the user certificate.