Schemes based on access control lists are sometimes referred to as identity-based access control because access policy is expressed in terms of ACLs, each of which applies to one specific user or to a class of users. The automated guard uses the identity presented by the user to determine if an ACL applies to that user. One question that naturally arises is: how does the user convince the guard that the presented identity really is that user's name? A related question is: what forms of credentials will the guard accept? The Directory addresses these questions by providing a standardized authentication service which supports several forms of credentials. Not all forms of credentials have to be supported by all implementations of the Directory; each implementor chooses which forms its DSA product supports. A full service DSA would support three basic forms:
When credentials contain only a name, the guard is given very little reason to believe the claimed identity. When a password is included, the guard has more confidence in the claimed identity. The standardized access control mechanisms assume passwords are carefully administered and protected to avoid ``weak'' and compromised passwords. Credentials consisting of a digital signature are considered to provide the highest level of confidence in the claimed identity. The standardized access control mechanisms assume a cryptographically strong public-key method is being used; they also assume there is a ``trusted'' key authority that can be used when verifying a digital signature.
The access control mechanisms allow the security authority to specify, for each ACL, the kind(s) of credentials that are acceptable. An ACL that specifies a default control applying to all users (e.g., ``public'' users) might require name-only credentials. An ACL that grants an ``insider'' permission might require password credentials. An ACL that grants administrative power (e.g., granting modify permission) might require a digital signature.
Before considering an ACL that grants a permission, the guard checks to see if the requestor has satisfied the authentication requirement for that ACL. A requirement for name-only authentication, the weakest requirement, is satisfied by any of the three basic forms of credentials. A requirement for password authentication, considered a stronger requirement, may be satisfied by either a password credential or a digital signature. A requirement for digital signature authentication is the strongest requirement and is only satisfied by a digital signature. ACLs which grant a permission are ignored by the guard unless the requestor has satisfied the authentication requirement specified in that ACL.
The authentication requirement in an ACL that denies a permission indicates the minimum level the requestor must satisfy in order not to be denied access. An ACL that denies and requires authentication via digital signature will, in effect, deny the permission to all users that do not authenticate with a digital signature. This is true regardless of the User Class specified in the ACL - a user who does not authenticate with a digital signature cannot adequately convince the guard that the denial does not apply. For users that do authenticate with a digital signature, the User Class in the ACL will determine whether or not the denial applies.
An interesting wrinkle in standardized authentication occurs when more than one DSA is involved in servicing a request. A request may be initially submitted to a DSA that does not contain the requested information. In such a case, there are situations in which the DSA automatically contacts another DSA and passes on the request; propagation of the request from one DSA to the next might occur several times before a DSA containing the requested information is found. When a request is passed among DSAs, it is referred to as a distributed operation.
There is one distributed operation scenario in which the final DSA is able to perform authentication of the user. This would be the case only if the request had been digitally signed by the user. The final DSA would then be able to verify that signature and apply the results to access control decision making.
In all other distributed operation scenarios, the final DSA cannot directly authenticate the user. For example, when password authentication is used, the initial DSA is the only one that receives the password and there is no standardized way for it to propagate the password to other DSAs. Also, it is possible that the user was authenticated only once by digitally signing a request to begin the Directory session. When authentication occurs only once at the beginning of a session, there is no way for other DSAs to receive the digital signature. Another new feature of the new edition of the Directory standard does, however, provide a way for the initial DSA to optionally indicate what authentication it performed. The indication is included in the operation arguments passed from one DSA to another.
The new feature allows the final DSA to make access control decisions based on user authentication performed by the initial DSA. This can only occur, however, when the final DSA trusts the first DSA and all intermediate DSAs to have properly handled the indicator of authentication level. Before the final DSA receives the indicator, any of the propagating DSAs could have purposefully caused it to be incorrect. This brings up questions about how a DSA knows what other DSAs it ``trusts'' and what happens when one of the propagating DSAs is not trusted.
The first question is addressed in implementation agreements produced by the OSE Implementors' Workshop. Under those agreements, each DSA maintains an internal list of the names of other DSAs it trusts to handle authentication processing properly (``proper handling'' is defined locally by each security administrator). A security administrator might also want to require each DSA to digitally sign the request so that there is high confidence in the identity of each propagating DSA.
When one of the propagating DSAs is not trusted, or when the authentication indicator is missing from a propagated request, the final DSA may assume no authentication was performed (i.e., name-only credentials), or it can make use of yet another new feature of the new Directory that allows the DSA to respond to the request by returning a ``referral'' to itself. Ordinarily, referrals are used to indicate other DSAs which may be able to respond to a request. However, when a DSA issues a referral to itself, it is, in effect, requesting the user to resubmit the request directly to that DSA so there are no propagating DSAs to trust. If the request is resubmitted directly, the DSA that issued the referral to itself is able to directly authenticate the user and use the results in making access control decisions.