You are not logged in Log in Join
You are here: Home » Members » petrilli » A Confidence Mechanism in User Role Management

Log in
Name

Password

 

A Confidence Mechanism in User Role Management

A Confidence Mechanism in User Role Management

Goals

The goals of the proposed confidence mechanism are primary driven by the needs of "portal" and application sites to...

  • Provide the ability to customize content/appearance on a per-user basis without requiring the user to provide any per-session authentication information.
  • Allow different levels of "authentication" to be realized and managed via a simple mechanism.
  • Provide backwards compatibility.
  • Provide near total application transparency.

Background

Currently, the Zope framework has a monolithic identification, authentication and authorization (IAA) framework. What this means is that the only transition from an Anonymous user to a "known" user is via a userid and password being provided. It has become apparent that this is unsuitable for many projects.

A note on terminology is in order:

  • Identification: The process of establishing the distinguishing character or personality of an individual.
  • Authentication: To prove or serve to prove the conforming to an original so as to reproduce essential features of a user.
  • Authorization: To invest official authority or legal power to a user.
  • Confidence: The faith or belief that one will act in a right, proper, or effective way.

These may seem a bit blurred, but it is best explained in the current context with the following items:

  • Identification is provided by the user's "username".
  • Authentication is provided by the user's "password".
  • Authorization is provided by the linking of the I&A information to Roles in the user database.

Currently, there is no expressed idiom of confidence in the environment, it is an "all or nothing" situation. Obviously there are times when you want to be able to separate the processes and understand different levels of each.

Proposal

This proposal's cornerstone is the concept of "confidence" in a user's status. In order to do this, it is necessary to tear down the current construct of how a user object is managed and re-introduce a more robust paradigm. To understand this, we will address each individual facet of the process and how it might look under this new approach.

User Object

The first change is a modification of the structure of a user object. First will be the introduction of a "confidence metric", which will be formally expressed. This will be an integer between 0 and 100, 0 implying that there is "no confidence" in who this User object represents (the traditional model of the Anonymous user), and 100, which mans we are absolutely certain who this person is (the current model of a normal identified user). To deal with this, I propose the following API introductions:

  • 'get_confidence()': This method will return the current confidence level of the user.
  • 'has_confidence(value)': Returns a Python true or false value based on the user's current confidence being superior (true) or inferior (false) compared to the provide value.
  • 'upgrade_confidence(value)': Increment the existing confidence metric by the provided amount.
  • 'downgrade_confidence(value)': Reduce the existing confidence metric by the provided value.

It should be noted that there is no explicit way to set the actual confidence metric. This is intentional. When the User object is instantiated, it has a confidence metric of 0, which may then be modified based on available information. All modifications are relative.

Identification

Under the current model, a user is not "identified" until they have logged in and provided a user id and password. Since this does not meet the goals of the project, it is necessary to introduce the ability to identify a user using other methods. Some possible options are:

  • Persistent cookies
  • IP address
  • X.509v3 certificates

By providing these options (and their different confidence modifications), it is possible to instantiate a User object which is no longer Anonymous.

Authentication

The current system only supports the use of passwords via HTTP basic authentication (and FTP) for this step. This is obviously acceptable for many situations, but there are several other authentication mechanisms which may be preferred or complementary:

  • X.509v3 certificates
  • NT Domain authentication (is this workable?)
  • Cookies

In addition, it may (and should) be important to differentiate the method by which these credentials are presented. A password sent as clear text may be less trustworthy than one sent over an SSL session. One might even argue that one sent over a 40-bit SSL session is less trustworthy than one sent over 128-bit SSL. These are all security officer decisions in the process of risk mitigation.

Authorization

In the current environment, a specific User object is granted roles based on a static choice in the database as well as "local roles" that are available in other parts of the system. In order to introduce the concept of confidence into the system a few things must be modified.

Several options were considered before Jim Fulton suggested the chosen one, which provides minimal (if any) impact on existing applications. The changes are all underneath in the internals of the user code, as well as changes to the management of roles.

Constraints

First, we introduce the concept of "constraints" on Roles. This concept means that you can constrain the situation under which a specific Role is available. Initially, we would express this only in a "confidence metric" range, i.e. 50-100, or simply 50, which would imply that level or above. If one wanted to specify a specific level, no higher, no lower, it would have to be specified as 50-50. While this is a bit cumbersome, it should only represent a tiny minority of situations.

In the future, one might imagine other constraints, for example...
  • Roles only available during certain time periods (weekdays between 8 and 5).
  • Roles only available based on certain subset restrictions, like HTTP vs. HTTPS, SSL strength, IP source, etc.
  • Roles only available based on attributes of a user's X.509v3 certificate.

While these are not currently planned, certainly this mechanism provides the framework for expressing much more interesting concepts.

User Object Creations

Second, on User object instantiation, we examine the granted Roles and evaluate their constraints in the current user confidence context. This allows us to grant the users only those Roles which are the intersection of the granted Roles and the restrictions placed on them. To talk about this in the correct vocabulary, we'll introduce two terms:

  • Granted roles: Those roles that are statically granted either in the user database itself or via local roles.
  • Available roles: These are the roles that represent the intersection of granted roles and the constraints.

This gets us to the point where we have a "customized" User object that has the Roles as appropriate for the current confidence metric expressed.

Role Transition

[Note: This is the least developed section and is only some ideas about how to handle things.]

The one thing left open is how does one increase the number of available roles. Take, for example, a user who has simply presented a cookie that they have stored in their browser, which has allowed them to possess the role of "Member". Now, however, they wish to manage their preferences, or purchase a product using stored information. This requires a role that they have been granted, but do not have available, called "AuthMember". The system would raise an Unauthorized, with additional information in the exception providing their current confidence metric, and the required metric. An exception handler could then calculate the needed actions and allow the user to provide a password that would grant them a high enough metric to continue.

While this is a bit of handwaving, it is something that would be very powerful in providing a robust user experience.

Open Issues

So what's unsettled? The following items:

  • Role transition and how to increase things.
  • How/why is the confidence metric recalculated?
  • Performance impact of the constraint checks?
  • Language for constraint expressions (I'm inclined to a "form" interface with pre-built options for now).
  • What else?