You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Authentication Requirements

Use Cases

  1. Standard Administrative Applications
    1. 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. 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. 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. 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. 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.
  1.  

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

  • No labels