More use cases

[Edward Clay <Edward.Clay@Sun.COM>]

All,

  I have added two medical use cases and one very complex DoD use case.  
Please let me know if I need to make any changes to this.

  Have a good one, Ed.

        Medical Insurance company

1. Customer wants to make changes to medical plan.  Insurance company 
has a portal for customer to check benefits, check for doctors in 
network, submit claim forms, claim statements, make payments, direct 
email, and making changes to their plan (coverage).  The company uses 
user name/policy number and password for users to enter the portal.  The 
company has given customers the option to come in and give a biometrics 
sample (finger print) to the insurance company (for a central template 
store) and they will give the customer a USB finger print reader for the 
customers system with software.  During that session the customer has 
the option to select which parts of the portal they would like to use 
biometric authentication to.  The customer can use policy #/user name 
and biometric authentication, policy #/user name, password, and 
biometrics to get authenticated, or policy #/user name and password to 
login into the system with specific tasks that require additional 
biometric authentication.

  A. User from cable modem using a router (with firewall, DHCP, and NAT) 
to connect multiple machines using NAT.  The user (customer) opens a web 
browser and connects to the insurance companies customer website.  The 
user is presented a screen asking for policy # or user name and a 
password.  The user is authenticated and given a menu of things they can 
do.  The user clicks to make changes to the policy.  The system then 
request the user to use the biometric reader for a given finger for 
authentication.  The customer is authenticated and given access to the 
policy change portion of the portal.

  B.User connecting via DSL opens a web browser and connects to the 
insurance companies customer website.  The user enters their policy 
#/user name.  The system asks for a finger to be used on the biometric 
reader.  The user uses the biometric reader to give the sample for 
authentication.  The user is authenticated into the users personal portal.

                    DoD

1. War fighter is out in the field conducting a mission.  The war 
fighter is given a non-state full device (GPS, network, small amount of 
ROM for certificates, USB, graphics, keyboard, and mouse) that uses 
TCP/IP satellite based communications to authenticate to a server 
located in a DoD protected facility.  The first part of the 
authentication process is to authenticate from the device to the DoD 
server. A large number of war fighter are using the same server to get 
their desktop and local applications with graphical data being sent back 
to the non-state full devices.  Some of the non-state full devices have 
built-in biometric devices, TCP/IP based devices, and some use USB 
connected devices.

  NOTE: Once biometric data is passed the session that initiated the 
authentication must be maintained.  The User, session, and browser needs 
to be kept tied together.

  Since the war fighter needs data from multiple sources each source 
(department/organization) needs to maintain control of who has access to 
their networks.  Federated identity or some other distributed identity 
system would be required due to the large number of users that each 
organization might have.  Each department/organization might not have 
the resources to individually check each user from other organizations 
to make sure they need access to resources.  However, based on current 
requirements US departments/organizations need to share certain data 
with other organizations.

  User from department (A) needs to get some data from department (B). A 
biometric authentication process is required from the user in department 
(A) to get access to data from department (B).  The template for the 
user will have to be passed from department (A) to department (B) with 
identifiers for user, organization, and department.  The sample 
(manusha) data will have to be passed from the user from department (A) 
in the field to department (B) with user data (user name, session ID, 
and originating server) for matching.  Department (B) will authenticate 
the user from department (A).  Department (B) will have to verify that 
users from department (A) has access to the requested data.  If 
authentication and authorization are confirmed data is passed back to 
the server in department (A) and displayed back to the war fighter in 
the field.