ARC1/Infosys/Access Use cases

Information access control use cases

Use case 1: Public monitor
Description	General public wishes to see basic information about a grid infrastructure (or a set of such), see Appendix for some examples. Public members are completely anonymous and do not identify themselves via certificates or other documents or means. No information about person's identity or location is available, not even a reliable IP address. Such individuals include visitors at an exhibition, journalists, policy-makers, school children and in general any creature or tool.
Participants	Anonymous end-users seeking information Grid services aggregating and publishing information (ISIS, ALIS) Optionally: intermediate services (gateways)
Pre-requisits	Resources and services advertise the necessary information Relevant information is available anonymously for public monitoring: for example, by anonymous queries directly to ALIS and ISIS, or via a set of authorized certified gateways
Devious flows	Used information schema does not include the relevant information Resources and services publish wrong information Local policies prevent publishing relevant information Local policies require blocking information access from specific domains or for citizens of specific countries Information access protocol or schema undergo a backwards-incompatible change which breaks the monitoring tools In case of a gateway-mediated access: expiration or revocaion of the gateway certificate

Use case 2: Information access by infrastructure administrators
Description	An privileged individual, e.g. an administrator or an operator-on-duty of a grid infrastructure that serves many VOs (such as EGEE or Open Science Grid) wishes to monitor status of the inrastructure. See Appendix for examples of monotored information. While the use case may be trivially addressed by making the administrator the member of every VO, this may not always be possible, as one can imagine mutually exclusive VO membership policies, or the procedure of obtaining the VO membership may be too time-consuming for practical purposes. This document does not intend to make any implementation suggestions.
Participants	Grid administrators and operators: individuals presenting an established proof of the privileged status, such as a special extended proxy certificate Grid services aggregating and publishing information (ISIS, ALIS) In case of relying on VO roles - VO management services
Pre-requisits	There is an established proof of the privileged status of an individual Resources and services advertise the necessary information Administrators/operators are authorised to access the information about each and every resource (for example, by means of belonging to a "super-VO", or having a special "role" in each VO)
Devious flows	Administrator/operator certificate has expired Privileged status of the individual can not be validated Used information schema does not include the relevant information Resources and services publish wrong information Local policies prevent publishing relevant information Local policies prevent authorization to access information for administrators/operators Local policies require blocking information access from specific domains or for citizens of specific countries Information access protocol or schema undergo a backwards-incompatible change which breaks the monitoring tools

Use case 3: Information access by VO members
Description	A VO member wishes to access information about resources that serve the respective VO; see some examples in the Appendix. A typical purpose is to discover resources and services that authorise the given VO members, and assess their status and capacity. If the VO supports roles and/or groups, the access pattern and amount of accessible information may depend on or be limited to the role or group affiliation of the individual in the VO. Roles and group membership in general are changing dynamically. Every VO defines which information should be visible to different roles and groups and to the outsiders.
Participants	Authenticated grid users, presenting a proof of VO affiliation (such as an extended proxy certificate) VO management services Grid services aggregating and publishing information (ISIS, ALIS)
Pre-requisits	Resources and services advertise the necessary information VO management services can produce the proof of VO membership There are means for VOs to specify which information should be visible to different roles and groups and to the outsiders
Devious flows	User certificate has expired User VO membership can not be validated VOs failed to define which information is accessible by whom Used information schema does not include the relevant information Resources and services publish wrong information Local policies prevent publishing relevant information Local policies require blocking information access from specific domains or for citizens of specific countries

Use case 4: Information access by peers
Description	A grid user wishes to share information about his/her activities and/or resource usage with a colleague or a number of other individuals, not constituting an established VO. Every participant is identified by their personal credentials, such as e.g. proxy certificates. A user may chose to share all the information available to him/herself with the selected peers, or a subset of this information, see some examples in the Appendix. In case the peers do not belong to the same VO as the user, they will not be able to see VO-specific information, such as e.g. the ist of VO resources or users. The case is similar to Use case 3 and can be regarded as a sub-case of it. While addressing this use case may imply addressing all the Use cases ##1-6, the reverse is not true. Moreover, applying the solution of this use case to e.g. Use case #3 may turn out to be suboptimal, especially for the very large VOs.
Participants	Authenticated grid users Grid services publishing information
Pre-requisits	Resources and services advertise the necessary information There are tools to create and advertise/propagate a list of trusted individuals (an "dynamic" VO) There are means for the user to specify which information should be visible to the selected peers and to the outsiders
Devious flows	User certificate has expired User failed to define which information is accessible by whom Used information schema does not include the relevant information Resources and services publish wrong information Local policies prevent publishing relevant information Local policies require blocking information access from specific domains or for citizens of specific countries

Use case 5: Personal user information access
Description	A user accesses complete set of information about resources available to him/her and grid tasks that are owned by him/her. This is the most basic and most common use case. A typical purpose is to discover resources and services that authorise the given individual, and assess their status and capacity.
Participants	Authenticated grid users Grid services publishing information
Pre-requisits	Resources and services advertise the necessary information
Devious flows	User certificate has expired Resources and services publish wrong information Local policies prevent publishing all the information pertaining to the user Local policies allow only privileged users to access specific kind of information Local policies require blocking information access from specific domains or for citizens of specific countries

Use case 6: System administrator information access
Description	System administrator wishes to access remotely (via standard grid monitoring tools) a complete set of information about the system he/she is in charge of. See the Appendix for some indicative examples. The use case is similar to the Use case 2 and can be regarded as a sub-case of it.
Participants	Authenticated grid users, presenting a proof of special privileges w.r.t. a given resource (such as an extended proxy certificate) Grid services aggregating and publishing information (ISIS, ALIS)
Pre-requisits	Resources and services advertise the necessary information There are means for the resource to distinguish between regular users and its own administrators (e.g. by making use of a "local" VO)
Devious flows	User certificate has expired Resource certificate has expired Privileged status of the administrator can not be validated Resources and services publish wrong information Local policies prevent publishing all the information pertaining to the user Local policies require blocking information access from specific domains Information access protocol or schema undergo a backwards-incompatible change which breaks the monitoring tools

Use case 7: Locate ISISes available for registration
Description	A privileged user, typically a system administrator, wants to discover ISISes to which he/she can register his system. For this, he/she needs a complete set of information pertaining to registration policies about all the available ISISes, such as for example those listed in the Appendix. At that point, the admnistrator is not expected to be a member of any VO, but is expected to be in possession of valid grid credentials. Alternatively, an ALIS service may attempt an automated ISIS discovery and matchmaking, without human assistance. In this case, the service should present the valid grid credentials, too.
Participants	Authenticated grid users and/or ALIS services ISISes publishing information
Pre-requisits	ISIS advertses all the relevant information about itself Relevant information is world-readable
Devious flows	User and/or service certificate has expired ISIS certificate has expired ISISes publish wrong information Information published by ISISes is not world-readable Local policies prevent publishing all the information about ISIS Local policies require blocking information access from specific domains

Use case 8: Authorisation of ALIS-to-ISIS registration and de-registration
Description	An administrator wishes to register his/her service (ALIS) to a suitable ISIS (e.g. selected as described in the Use case 7). A reverse operation (forced de-registration) can also be foreseen. ISIS then choses whether to grant the registration request or no, based on the local policies and credentials presented by ALIS. The human administrator is not expected to present any personal credentials or to interact with grid security systems in any manner, and thus remains anonymous. In case ISIS policies require presence of personal credentials of ALIS administrators, there must be a way to associate an individual with a set of resources, on behalf of which he/she can operate (a "reverse proxy"?) In case ISIS is not a standalone service, but a part of a "cloud", the policies of ISISes forming such a "cloud" are expected to be synchronised. In case Virtual Otganizations are defined as consisting of not just humans, but also of devices and services, authorisation process can make use of the ALIS VO-affiliation. In this case, there must be a way to validate that ALIS belongs to a VO.
Participants	ALIS, optionally presenting an established proof of VO affiliation ISIS (or a "cloud" of ISISes") Optionally: VO membership services Optionally: privileged individuals, presenting an established proof of affiliation with ALIS
Pre-requisits	ALIS presents a valid service certificate and optionally a credential proving VO affiliation ISIS presents a valid host certificate Optionally: there is a way to register ALIS (and ISIS) services in VOs Optionally: there is a way to affiliate a human user to a resource that he/she manages
Devious flows	ALIS certificate has expired ISIS certificate has expired Local ISIS policies require blocking access from specific domains ISIS policies are improperly advertised Optional: ISISes in the cloud have conflicting policies Optional: ALIS VO affiliation can not be verified Optional: affiliation of the administrator with ALIS can not be verified

Use case 9: Inter-ISIS information synchronisation inside the "cloud"
Description	The use case assumes existence of a "cloud" of ISISes. Since different ALIS instances may register to different (but not all) ISISes in the "cloud", there must be a procedure for inter-ISIS information synchronisation inside the "cloud". This synchronisation can be "anonymous" w.r.t. credentials of the registered ALISes, if the "perimeter" access control rules are synchronised between all the ISISes. In general, different ISISes may chose to exercise different registration policies, and only a subset of the registered ALISes may turn out to satisfy the common policy and get their registration entries propagated to all the ISISes in the "cloud".
Participants	ISISes constituting a "cloud"
Pre-requisits	ISIS presents a valid host certificate ISIS advertises information sufficient to replicate the registration entries (all the necessary details about every registered ALIS, optionally including ALIS credentials)
Devious flows	ISIS certificate has expired Local ISIS policies require blocking access from specific domains ISIS does not advertise ALIS information needed for synchronisation ISISes in the cloud have conflicting policies

Appendix: Examples of service/resource description attributes

Description of a grid infrastructure

Possible examples of anonymously available public information:

• Geographical location of resources and services
• Nature of each resource (storage, computer, database etc)
• Total capacity of each resource
• Current occupancy of each resource
• Lists of served VOs
• Project affiliations
• Administrative resource ownership
• etc

Examples of information available for authorised infrastructure operators:

• The list of the infrastructure services and their nature, such as:
• computational resources
• storage facilities
• VOs and associated services
• data indexing services
• logging/accounting services
• information indexing services
• etc
• Status of each service, such as:
• Up
• Down
• Scheduled maintenance
• Unknown
• Total capacity of each resource, when relevant
• Current load of each resource, depending on its nature, e.g.:
• nr of running jobs
• percentage of used storage
• nr of VO members
• etc
• etc

VO-specific information

Examples of information accessible by VO members only:

• List of services, including e.g.
• computing resources
• storage
• databases
• etc
• Details of jobs belonging to the fellow VO members, e.g.:
• status
• resource consumption
• etc
• Details of data owned by the VO members, e.g.:
• dataset/file names
• dataset/file size
• dataset/file location
• VO-specific metadata
• etc
• List of other VO members
• etc

User-specific information

Examples of information accessible by explicitly authorized users only:

• Details of jobs belonging to this user, e.g.:
• location
• status
• resource utilization
• etc
• Details of data owned by this user, e.g.:
• logical names
• physical names
• dataset/file size
• dataset/file location
• VO-specific metadata
• etc
• etc

System-specific information

Examples of information accessible by local system administrators only:

• Status of the system and the services
• Load, depending on the nature of the system, such as:
• number of jobs
• storage occupancy
• number of concurrent database accesses
• etc
• List of authorised VOs and users
• Details of the installed software
• etc

ISIS information

Examples of information published by ISIS, accessible by authorised users:

• Authorised VOs
• Authorised domains
• Authorised service types
• Geographical location
• Contact information
• etc