Navigation: ()

Security Model/Architecture

Identifiers

There are four identifiers associated with a user:

1. the user's login name - what the user types into the login page (along with their password) (step 1 above).
2. the user's authentication-id - the id returned by the login service when validating a ticket (step 3 above).
3. the user's internal (topaz) id - the id used to identify a user's account in topaz.
4. the user's display name - displayed on web-pages wherever a reference to a user is made.

A given user may have multiple login names and authentication-ids (for example if they have accounts with multiple login services); however, they will only have a single internal id and display name (two different internal ids are considered two different users).

While the user only sees the login and display names (1 and 4), the topaz software only deals with the authentication-id and internal id (2 and 3).

When a user logs in they provide their login name. Next, when the user's ticket is verified, the login service returns the user's authentication-id, i.e. the login service maps user names to authentication-ids. The authentication-id may be the same as the user's login name (often the case), but need not be - this allows the login service to provide the capability for a user to change their login name without requiring notifications and updates to the topaz accounts. This is useful, for example, when the user's email address is used as the login name.

After retrieving the authentication-id, it is mapped to the user's internal id via topaz API's (this functionality is provided by the UserAccountsFilter). This second mapping is to allow support for multiple login services and for easy mobility among those; any number of authentication-ids may be mapped to a single internal id.

Additional Functions

The presumably common case will be for a user's login name to be their email address, and presumably in most cases the login service will verify that email address during registration. In order to avoid the user having to enter their email address a second time when setting up the topaz account and having to go through email address verification a second time, the login service may provide a mechanism to retrieve the user's login name. In the case where the authentication-id is the same as the login name, this is not needed of course.

Tomcat CAS-BASIC authenticator valve in Fedora

Question

Interestingly I found some oai testing I was doing was going through cas. I don't remember being prompted for authentication when I was playing with oai, but I found this URL stuck in my browser cache: https://localhost:7443/cas/login?service=http%3A%2F%2Flocalhost%3A9090%2Ffedora%2Foai%2F%3Fverb%3DIdentify This was for http://localhost:9090/fedora/oai?verb=Identify. Why doesn't cas prompt me for authentication in this instance?

Answer

Normally a CAS Filter will be inserted in the web.xml for authentication (like we did for Topaz). This would make the only auth scheme available as CAS. But for Fedora, I have inserted a Tomcat authenticator valve for doing a bunch of things:

1. Support both CAS and BASIC auth clients simultaneously
2. Support direct user access to Fedora with CAS auth
3. Be compatible with Fedora's use of JAAS Realm and the user attributes that are visible to xacml policies
4. Be compatible with Fedora's Surrogate authentication

But there is a side effect though. Clients that are configured with BASIC auth has the logic to first try to access with no credentials and if that fails present the auth credentials. This usage for us is indistinguishable from (2) and therefore there will result in a redirect to CAS server login page. This is what you saw with the OAI service.

The work around is to configure clients that wish to use BASIC auth to always present the credentials - or configure our tomcat CAS valve to disable support for (2).