1. Shared authentication scenario:
An agent authenticates to the central authentication service of the agent's home organization. Several applications including O.K.I. make use of this service. This scenario would support various mechanisms such as certificates, kerberos, and single sign-on technologies such as Inernet2/MACE webISO
2. Agent performs some tasks anonymously and then logs in:
An agent visits an unrestricted portion of an O.K.I. application anonymously, following which the agent seeks access to a restricted portion where identification and authentication are required. Once this is accomplished, the agent is known and is understood to be the same person as before.
Special consideration: Because of firewall configuration, the secure portion may show a different ip address from the insecure portion.
3. Other authentication needed:
An authenticated agent has performed several tasks already in O.K.I. service A and then selects O.K.I. service B, which does not accept the type of the agent's authentication. O.K.I. service B sends the agent to be authenticated acceptably.
4. Access negotiated via Shibboleth:
An agent requests O.K.I. services of remote site. The remote site uses Shibboleth to find out whether the person is authenticated in his/her local domain and to get attributes in order to determine eligibility.
5. Pseudonymous authentication:
An agent wants (and is allowed) to use O.K.I. services semi-anonymously. That is, he/she is known as the same person from session to session, but the identity is not tied to the one used in authentication.
6. O.K.I. log-out scenario:
An authenticated agent logs out of O.K.I.. Afterwards he/she is not known to the system, and O.K.I. services should remove the agent's session.
7. External log-out scenario:
An agent has authenticated as per Shared authentication scenario and then logs out using a service external to the O.K.I. system. In logging out, the agent elects to logout of all applications currently in use (including O.K.I.).
8. Time-out:
The central authentication process has defined a maximum allowable idle time and when that is exceeded, the person is "logged out", i.e., no longer considered to be authenticated. The O.K.I. services must recognize this and drop session(s) for the agent.
9. Kiosk use:
Person authenticates from a "kiosk", i.e., a shared public workstation, using Shared authentication scenario. (under analysis currently (3/2002) by the I2/MACE webISO group.)
10. Authorization needs authentication server info to determine where to find attributes.
This is an authorization scenario, but it is included here to illustrate the need to pass this detail of the authentication process to other shared services.
1. Agent getAgent()
- org.O.K.I.p.service.common.api.Agent getAgent()
- throws org.skip.service.common.api.Exception;
- Returns an authenticated agent associated with the current session
2. Type[] getAuthenTypes()
- org.O.K.I.p.service.shared.api.Type[] getAuthenTypes()
- throws org.O.K.I.p.service.common.api.Exception;
- Returns all authentciation types known to the implementation.
3. Type getDefaultAuthenType()
- org.O.K.I.p.service.shared.api.Type getDefaultAuthenType()
- throws org.O.K.I.p.service.common.api.Exception;
- Returns the authentciation type defined as the default. If one is not defined, it must return an exception.
4. void setDefaultAuthenType(Type authenType)
- void setDefaultAuthenType(org.O.K.I.p.service.shared.api.Type authenType)
- throws org.O.K.I.p.service.common.api.Exception;
- Allows one to define the authentication Type
5. Type[] getAuthenTypes (Agent agent)
- org.O.K.I.p.service.shared.api.Type[] getAuthenTypes (org.O.K.I.p.service.common.api.Agent agent)
- throws org.O.K.I.p.service.common.api.Exception;
- Returns all types used in authenticating this agent. If the agent has not been authenticated, it throws an exception.
6. Boolean isAuthenticated(Agent agent, Type authenType)
- Boolean isAuthenticated(org.O.K.I.p.service.common.api.Agent agent, org.O.K.I.p.service.shared.api.Type authenType)
- throws org.O.K.I.p.service.common.api.Exception;
- Returns true if the agent is authenticated by the given type.
7. Boolean isAuthenticated(Agent agent)
- Boolean isAuthenticated(org.O.K.I.p.service.common.api.Agent agent)
- throws org.O.K.I.p.service.common.api.Exception;
- Returns true if the agent is authenticated.
8. Agent getAgent(Agent agent, Type type)
- org.O.K.I.p.service.common.api.Agent getAgent(org.O.K.I.p.service.common.api.Agent agent, org.O.K.I.p.service.shared.api.Type type)
- throws org.O.K.I.p.service.common.api.Exception;
- Requests the agent be authenticated according to the given authentication type.
9. void destroyAuthen(Agent agent)
- void destroyAuthen(org.O.K.I.p.service.common.api.Agent agent)
- throws org.O.K.I.p.service.common.api.Exception;
- Change the status of agent such that he/she/it is no longer authenticated.
10. void destroyAuthen(Agent agent,Type type)
- void destroyAuthen(org.O.K.I.p.service.common.api.Agent agent,org.O.K.I.p.service.shared.api.Type type)
- throws org.O.K.I.p.service.common.api.Exception;
- Change the status of agent such that he/she/it is no longer authenticated with the provided authentication type.
11. void destroyAuthen(Agent agent,Type[] types)
- void destroyAuthen(org.O.K.I.p.service.common.api.Agent agent,org.O.K.I.p.service.shared.api.Type[] types)
- throws org.O.K.I.p.service.common.api.Exception;
- Change the status of agent such that he/she/it is no longer authenticated with the provided authentication types.
1. Shared authentication scenario:
Description: agent authenticates to the central authentication service of the agent's home organization. Several applications including O.K.I. make use of this service. This scenario would support various mechanisms such as certificates, kerberos, and single sign-on technologies such as Inernet2/MACE webISO
Pre-conditions: The agent is not authenticated and is therefore not known or trusted by any of the applications including O.K.I. that rely on the shared authentication service. (note this group of applications could have only one member)
Post-conditions: The agent is authenticated according to the authentication type of that service and is known to the all of the applications in the group. Agent identifier, authentication status, and authentication type are passed to the O.K.I. application.
Alternate outcomes: Authentication failed
2. Agent performs some tasks anonymously and then logs in:
Description: An agent visits an unrestricted portion of O.K.I. application anonymously, following which the agent seeks access to a restricted portion where identification and authentication are required. Note: Because of firewall configuration, the secure portion may show a different ip address from the insecure portion.
Pre-conditions: The agent is not authenticated, although the O.K.I. service has session and other activity information gathered in the course of the session about this otherwise anonymous person.
Post-conditions: The session continues and is now associated with an authenticated agent.
Alternate paths: The agent fails authentication. Session can continue as before in the unrestricted portion of the application.
3. Other authentication needed:
Description:An authenticated agent has performed several tasks already in O.K.I. service A and then selects O.K.I. service B, which does not accept the type of the agent's authentication. O.K.I. service B sends the agent to be authenticated acceptably.
Pre-conditions: Authentication completed as per Shared authentication scenario. agent has performed several tasks already in O.K.I. service A and then selects O.K.I. service B, which does not accept the authentication type.
Post-conditions: The agent is re-authenticated. The "authentication type" for this new authentication is acceptable to O.K.I. service B. All authentication types performed on this agent in this session are known to the O.K.I. system.
Alternate paths: The agent fails this authentication. All prior authentications are still valid, however, and the agent can still use any of the O.K.I. services that will accept them.
4. Access negotiated via Shibboleth:
Description: An agent requests O.K.I. services of remote site. The remote site uses Shibboleth to find out whether the person is authenticated in his/her local domain and to get attributes in order to determine eligibility.
Pre-conditions: The agent seeks access to an O.K.I. service at another institution. Both the home organization and the O.K.I. site at the remote organization are Shibboleth-enabled.
Post-conditions: The agent is authenticated to the O.K.I. system. Identity may or may not be the same as was used to authenticate.
Issues/Comments: Alternate paths -- this involves a combination of authentication and authorization. One can imagine an implementation that supports the separation of these functions, however, by setting authentication and authorization interfaces to the Shibboleth Attribute Requestor (SHAR) possibly through a gateway.
5. Pseudonymous authentication:
Description: An agent wants (and is allowed) to use O.K.I. services semi-anonymously. That is, he/she is known as the same person from session to session, but the identity is not tied to the one used in authentication.
Pre-conditions: The agent is unknown and unauthenticated
Post-conditions: The agent is identified consistently from session to session but there is no way for the O.K.I. application to trace back to the agent's actual name.
Issues/Comments: Shibboleth addresses this scenario.
6. O.K.I. log-out scenario:
Description: An authenticated agent logs out of O.K.I.. Afterwards he/she is not known to the system, and O.K.I. services should remove the agent's session.
Pre-conditions: The agent is authenticated and using O.K.I. tools and services.
Post-conditions: The agent is no longer authenticated to any of the O.K.I. tools and services.
7. External log-out scenario:
Description: An agent has authenticated as per Shared authentication scenario and then logs out using a service external to the O.K.I. system. In logging out, the agent elects to logout of all applications currently in use (including O.K.I.).
Pre-conditions: The agent is authenticated and using O.K.I. services.
Post-conditions: The agent is logged out of all applications making use of the shared authentication service.
8. Time-out:
Description: The central authentication process at the agent's home organization has defined a maximum allowable idle time and when that is exceeded, the person is "logged out", i.e., no longer considered to be authenticated. The O.K.I. services must recognize this and drop session(s) for the agent.
9. Kiosk use:
Description: Person authenticates from a "kiosk", i.e., a shared public workstation, using Shared authentication scenario.
Issues/Comments: Some use cases from webISO
- (a) A workstation in a university common area that is meant
for short personal use: A student might want to check their
calendar or send a short message. So authentication is required
but coO.K.I.es should be short lived. (b) A workstation in a library
: Authentication is anonymous but can be long lived. The location
of the workstation grants certain entitlements (access to library
licensed databases) (c) A workstation in a laboratory or common
area with limited access: Authentication is anonymous but access
is limited to a set of applications. (d) A handheld device :
The device belongs to one person and authentication is inherent
to that person by physical ownership. (under analysis currently
(3/2002) by the I2/MACE webISO group.)
Issues: Authentication-individual or anonymous, manual or automatic coO.K.I.es : duration should be settable to short-lived ( first case), normal, or long-lived
Entitlements/authorization: these can be granted or limited independent of authentication but might be based on physical location, ownership or pre-configuration.
10. Authorization needs authentication server info to determine where to find attributes:
Description: This is an authorization scenario, but it is included here to illustrate the need to pass this detail of the authentication process to other shared services. The authorization service uses the authentication process to figure out where to look for information about the agent, which it needs to determine eligibility.
Issues/Comments:There are cases where the information coming from the authentication process is necessary for the authorization process to get information about the agent.
