Andrew Authorization Central
DRAFT

1.0 Introduction

This project attempts to address the problem where applications are more and more being required to follow a central authorization policy. Traditionally, this has required that applications be modified whenever a policy changes. This project will provide an alternative to this problem.

This goal of this project is not to design a generic authorization system that will be used for every authorization check an application may make. Instead, you can think of this system as a doorman: it will do some very coarse grained checks. The application will likely still do some form of internal authorizations for most operations.

From the application point of view, all that will need to be done to use this system is make an authenticated LDAP query.

The system that will first use this infrastructure is Andrew For Life (http://asg.web.cmu.edu/isam/proj/afl). Specific details on how applications are to be changed will be discussed on that project page.

We expect to use this system for at least the next few years. This system does not preclude a more advanced authorization system from being deployed in the future. We needed a solution for the short run and the existing systems were not mature enough and too heavy weight for immediate deployment.

2.0 System Overview

The following provides an implementation independent overview of what we are trying to achieve.

2.1 Definitions

We define the following terms in order to avoid any confusion based on pre-assumptions.

authorization group

The authorization group is a named value that consists of the entitlement, white list, black list, and final authorization. An example of something that would be represented by an authorization group is the ability to use the campus modem pool for dial-in.

entitlement

The entitlement defines the access a user should have, usually this will be based on enterprise directory data. For example, if a user is a student, then they will be entitled to use the modem pool.

white list

The white list allows the administrators (either application or central) to explicitly grant access to a specific user. This will supercede any information from the entitlement. For example, a visiting alumnus who wants to give the university a ton of cash can be placed into the white list and be given access to the modem pool, even though the entitlement indicates that he should not have access.

black list

The black list allows the application administrators (either application or central) to explicitly deny access to a specific user. This will override both the entitlement and the white list. For example, the black list can be used to deny the student access to the modem pool even though he has the entitlement to use it.

final authorization

The final authorization is the specific access the user has at this point in time. This is determined by the evaluation of the entitlement with the corresponding white list and black list.

central policy

The central policy uses the enterprise directory to generate the actual entitlement.

2.2 Data Flow

The basic data flow, building upon the definitions above, is shown in the following diagram:

The identities from the enterprise directory gets transformed by the central policy into a list of people entitled to the resource. The white list adds people not in the entitlement list; the black list removes people from the merged list. At the end, we have the final authorization which the application queries.

Parviz alternate view:

2.3 Server Information

We continue with the model of having a directory with all the information in it. However, we will continue to have non-users use application specific CNAMEs. This gives us the flexibility of having different machines with different representations of the directory in the future. This way applications may not need to change anything in order to use the new servers.

We use 'Oracle' to refer to our current database. If it makes you feel better, please replace 'Oracle' with 'directory SQL database' any time you see the string Oracle in this document.

2.4 Person vs. Account

There is the general issue of when should authorization be done against the Account that one authenticated with vs.. the Person that the account is associated with.

In some instances, using the Person is a convenience for the user. For example, if someone wants to change their benefits, then it may not matter if they are using their Andrew ID or their CS ID or their ECE ID. Ideally, you'd want to accept the authentication from any source you trust.

On the other hand, if an account has been granted elevated privilege in a domain, you want to ensure that the user authenticated with that account and not an account from a different domain. This way, you don't grant administrators in the other domain elevated access.

Whether to use the Person or the Account is very application specific. We will try to provide as specific guidance as possible in section 3.0.

3.0 Application Guidance

3.1 Application Query

The LDAP query an application would make is:

    server:     ldap-authz.andrew.cmu.edu
    searchbase: cn=name_of_authorization_group,ou=Authz,dc=cmu,dc=edu
    scope:      BASE
    filter:     member=GUID
    attrs:      none
 
    Search will return 0 or 1 entries.

If the search result returns 1 entry then the user is granted final authorization. If the search result returns no entries, then the user is denied final authorization.

3.2 Application Setup

3.2.1 Scope

The primary scope of the authorization is to provide a doorman function. This means that we expect the bulk of the clients will be using this to determine whether or not the given user will be allowed to access the service in general. Service specific authorization (i.e. filesystem, bboard ACLs) will likely be done independently by the application.

It is also likely that a service will be able to use this, along with the current trigger mechanism, to provision or expunge a user, if needed, from their service. Please refer to section 3.2.3 for details.

If an application can take advantage of the system to do more than these functions, we encourage the application to pursue this path. We believe that moving authorization out of a application is the way of the future. Please be sure to talk with the Architecture Group about these plans.

3.2.2 Naming

We will infringe on the MACE URN space with the expectation that the system may be more generalized.

The prefix will be urn:mace:cmu.edu:andrew:. Whatever follows after andrew can be selected by the application.

More guidance on naming is found in section 3.2.3.

3.2.3 Provisioning/Expunging

Some services may require setup (provisioning) before first use and those services may also require cleanup (expunging) when no further use is expected.

We expect the application to be notified via the existing trigger delivery system. Since that is unauthenticated, the application will need to do a lookup to validate the authenticity of the request.

Given the boolean nature of the current query and the fact that only the final authorization is visible via LDAP to the application, the application can not just use the final authorization. The application does not know if the user is not entitled or if the user is black listed. As such, a separate authorization group needs to be created to indicate whether or not the user should be provisioned.

An example of this would be the following:

  cn=UnixAccount,ou=Authz,dc=cmu,dc=edu
  cn=UnixAccountLogin,ou=Authz,dc=cmu,dc=edu

The first group is to allow one to test for whether or not the given account should be provisioned or expunged. The second test is to determine whether or not the user has access to the provisioned service.

It makes no sense for UnixAccountLogin to be true while UnixAccount is false. Rather than work in complicated logic to link the two, we know that the two will have the same entitlement if the same central policy is applied.

TODO: maybe this argues for exposing the whitelist+entitlement as an app can look at that for provisioning/expunging?

3.2.3 Central Policy Creation

A web interface will create a set of central policies. These policies will then be applied to each authorization group.

The web interface will provide a list of "building blocks" that the enterprise directory provides and allow one to create a central policy by joining these blocks with and and or operations.

The central policy will be given an identifier that can be applied to multiple authorization groups. This allows the same policy to be consistently applied to multiple authorization groups.

It is likely we will provide an initial set of central policies.

TODO: If we change the semantic meaning of a central policy, how do we know if the authorization group wants this change or wants to have the old semantics?

3.2.5 Account vs. Person

what is in the group? account/person. App should know but how does the trigger know how to populate the group? Probably will not allow an authorization group to have a mix of accounts and people.

3.3 Application list management

TODO

• API/web interface to add/remove things to the black list / white list
• Locking issues with multiple writers?
• Inheritance of the lists to related authorization groups?
• Should a user be removed from the black list if he is no longer entitled? If not, when does the black list get cleaned up?
• Should a user be removed from the white list if he appears in the entitlement? ? If not, when does the white list get cleaned up?

3.4 Application Questions

• Would the application want to:
  • Query the white list? If so, how would the application use this data?
  • Query the black list? If so, how would the application use this data?
  • Query the entitlement? If so, how would the application use this data?

4.0 Support Guidance

There will be a debugging web page that will allow you to peer into the inner workings of the system in addition to the various logs. This page will expand out the central policy and thereby be able to show exactly which test was failed and why the user does not appear in the final authorization.

TODO:

• Naming - how do I find the appropriate name?
• how to find out of a user is in the white/black list?
• Does everything get logged to the DAMS history? whenever a user gets added/removed to every entitlement/white list/black list? Is this too much data?

5.0 Implementation Details

• We choose not to expose anything but the final authorization via LDAP. There is some question about the utility of these items, especially since we will be providing the support page described in Section 4.
• The central policies are just a set of PLSQL triggers.
• changes to the white list/black list will also trigger changes to the final authorization.

5.1 Implementation Assumptions

• authz are boolean values - We understand that we limit the flexibility by doing so. For example, this means that we can reasonably represent quota (i.e. email quota) with this system.

5.2 Implementation trade-offs

How we got here:

The authz center proposal (referenced below) implements the authorization attributes as LDAP attributes associated with a user. One of the biggest drawbacks with this approach is to add additional authorization attributes, a schema change is required. With the OpenLDAP implementation that we are currently running requires a server restart for it to occur.

Another proposal was to use eduPersonEntitlement (referenced below). In this manner, the authorization attributes would just be values in the eduPersonEntitlement field. This solved the problem of schema changes but introduced a couple of issues:

• privacy - the current server does not allow one to have different ACLs per value. As such, a person's entitlements could be gleaned and this could be a privacy violation.
• conflict with Internet2 - this attribute is being used by Internet2 for Shibboleth. For example, there could be problems where this list is very large and content providers using Shibboleth can't handle the list.

The use of the groups mechanism described above allow us to restrict read-access to the authorization attribute and does not require schema changes and therefore server restarts for new authorization attributes to be added.

5.3 Implementation Evaluation

• Lookup speed of large groups?
• Lookup speed of enumerating all authorization group names?

6.0 QA

What about naming conflicts with other LDAP groups?

We will put these groups in a separate part of the DIT. If someone does a search from the root, then there may be come confusion. However, by having it in a separate area, we don't have to worry about name conflicts.

Why are black/white lists are necessary?

The problem is that the enterprise directory data may add or remove people from the group. Without separate white/black lists, there is no way to determine whether or not the enterprise data should actually change the values.

With only one list, we'd run into the following problem:

1. Application takes user X out of the group to explictly deny the user access (for example, the user has abused the service).
2. User X's 'affiliation' changes so that he is entitled to the service.
3. Entitlement trigger puts user X back into the group.

The problem comes in the last step. The lack of the user in the group could be either (a) the user was not previously entitled or (b) the user is blacklisted. Thus, we need another list.

What is the order of evaluation of the lists?

The white list is applied first, then the black list. This means that if an identifier appears in both lists, the black list has precedence.

Appendix A: Examples

Appendix A.1: Provision New user

Appendix A.2: Black list User

Appendix A.3: Expunge Deleted user

Appendix B: Document Trail

• Early ponderings. Presentation at the CSG: [csg-authz.pdf]
• Authz center proposal: [authz-center-req.htm]
• Adamson's reply: [adamson-authz-reply.txt]
• 6/18 Meeting
• Meeting agenda: [2003-06-18-agenda.txt]
• Meeting minutes: [2003-06-18-minutes.txt]

Appendix C: References

Related Systems:

• Ponder - http://www-dse.doc.ic.ac.uk/Research/policies
• GAA API - http://www.isi.edu/gost/info/gaaapi/gaa_api.html /li>
• Barton's SAGE -
• MIT Roles DB - http://web.mit.edu/rolesdb
• NIST Role-based Access Control (RBAC) - http://csrc.nist.gov/rbac

"Source" documents:

• Visio source for authorization attribute flow: authz-flow.vsd. [XXX DOH CVS wasn't in binary and blew it away... ]
• PowerPoint Source for CSG presentation: authz.ppt.

ChangeLog

0.6   - wcw         - 01/16/2004 - deprecate document
0.5   - wcw         - 06/25/2003 - filling more things in
0.4   - wcw         - 06/25/2003 - finished adamson merge
0.3   - wcw         - 06/24/2003 - some html cleanup; started merge from adamson
0.2   - wcw         - 06/24/2003 - added some comments/questions/corrections from tgd
0.1   - wcw         - 06/19/2003 - Initial draft

Global todo

Added by wcw:

• Pass through document to clean up repeating text, reording text to make things more clear, make simpler sentences and more bullet points rather than lengthy prose.
• Does this significantly stomp on/redefine any I2 terms?
• Discuss differences, specifically pointing out the difference between business apps and infrastructure apps.
• bunch of stuff in section 3 and 4.
• apps use other ones
• clearly define permissions
• writers to whitelist/blacklist? central way or each app?
• must detail specifically what is in the groups (white list, black list, final authorization)
• reason modifier for addition to whitelist/blacklist

Added by ???:

• ???