Authentication Requirements

Use Cases

1. SUBSET OF MIT COMMUNITY: Standard for most MIT 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 telling them how to get an MIT certificate.
   3. ACCESS DENIED: 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. IMPERSONATE: If the user knows the right password she can log in as another user, get the roles of that other user and look to the system as the other user.

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