Authentication Requirements

Use Cases

1. NAMED SUBSET OF MIT COMMUNITY: Standard Administrative Applications
   1. UNSECURE PORT: If user tries to enter the application via a non-SSL (unsecure) port then the application should display a page that does the following:
      1. Display a statement saying that this application requires a client certificate
      2. Displays a link to tell the user how to obtain an MIT issued certificate.
      3. Gives the user the SSL version of url for them click
   2. NO CERTIFICATE: If the user tries to enter the application via the SSL (secure) port and the user does NOT have a valid MIT issued client side certificate then the user should be routed to the non-SSL port in (1) above.
   3. NO AUTHORIZATIONS: If the user has a valid client certificate but does not have ANY authorizations for this particular application then the application should display a page that tells user who to contact to get the required authorization.
   4. VALID USER: If the user has a valid client certificate AND at least one authorization for this particular application then the user should be allowed into the application.
   5. SWITCHING: If the user first comes in via the SSL port then switches to the unsecure port the application should detect this present the same situation as (1) above.
   6. MIDDLE OF APPLICATION: If a valid user first comes into the application at some url that is NOT the main entry point for the application the programmer needs the OPTION to be able to prevent this and to route the user to the main entry point instead.
   7. IMPERSONATE: If the user has a valid client certificate PLUS a special "impersonate" authorization and the user goes to a special impersonate entry point then the user should be prompted for the person whom they wish to impersonate.

Authentication List

1. Cannot just get a String, need to be able interrogate type of token.
   1. User user = securityMgr.getCurrentUser ();
   2. user.getType (); (i.e. Kerberos, MIT ID, email address, Alumni ID, etc)
   3. user.convertTo (type); - allows programmer to convert between supported types
2. Service layer access to authenticated user without having it explicitly passed in each call
   1. i.e. User user = securityMgr.getCurrentUser (); works on service layer just as it does on the web tier
   2. A way to do machine to machine authentication (or app to app authentication)
   3. An ability to invoke service method on behalf of a named business user
3. Ability to impersonate another for testing just within a particular application
   1. Grant Impersonate to X for application Y
   2. UI to let X type in user Z to impersonate them within the rest of the application
   3. User user = securityMgr.getCurrentUser (); // must return Z
   4. User user = securityMgr.getTrueUser (); // optional to return X

Authorization requirements

Below are the documents that came out of the GASP/ISDA meetings:

AuthorizationModelForCombiningExplicitAndImplicitAuthorizations.vsd

GASP Authentication Issues.doc

GASP Authorization Issues.doc