Login

Just a page to noodle on login issues:

1. When there is only one place to authenticate a user, life is easier. For many installations, this will be the case and a simple UX should be available for such installations. The simplest situation is for institutions using the internal Sakai user accounts and the registration page, but from a UX perspective having a single external login (e.g. Kerberos/CAS) is comparable.
2. Some installations will have more than one way to authenticate a user. Of those, several will have just 2
   1. An institutional directory of some kind plus a secondary directory for loosely affiliated people (e.g. Michigan with Kerberos and Friends) 
      
   2. An institutional directory plus some Sakai internal accounts serving the same purpose as the second directory of loosely affiliated people
3. In general, institutional policy can be expected to require 'loosely affiliated' people to have more restricted access than 'official' members of the institution. This represents a less than ideal mixing of Authentication (they are who they say they are) with authorisation (because of who they are they can do more or less). Of course, the secondary directory may represent a different level of certainty that they are who they say they are as well as a different category of users.
4. In seeking to make Sakai more open, the situation is likely to become more complex.
   1. We will probably begin to support authentication that we do not control (OAuth, Shibboleth)
   2. We will start to have pages that display different content depending on whether a user is authenticated and the authorisation level (permissions) of that authenticated (logged in) user.
5. It should somehow be clear that someone with an account may get more information if they log in
6. We should have a clear path for intercepting access to protected deep links and directing users to a login
7. It may be desirable to enable login preferences to be retained (e.g. always take me to Kerberos)