OGSA-WG Security Use Cases Jan 29, 2004 Takuya Mori <moritaku@bx.jp.nec.com> NEC Corporation

Contents Overview of a VO Use Cases Security Services Digital Libraries Security Services Creation of VOs Trust Management Identity Management Service Invocation

VO: Overview A VO gathers users and resources across security domains to form a virtual security domain that enables secure service invocations across the security domains. Flexible authorization patterns are supported within a VO. There may be many flexible management patterns of attributes and policies. A VO is so dynamic that it can be created at any time when it is needed. service_x user 1 service_c user p service_a service_y Virtual Organization Services and Users are exposed in a Virtual Organization Organization A service_c service_b service_a user 2 user 3 user 1 service_z service_x service_y user p user q user r barrier Organization B

Required Functionalities for VOs The following functionalities are required for VOs Federation (Identity) Services Federation Services can provide federated identity assertions for users or resources. Attribute Authorities Attribute Authorities can issue attributes bound to users or resources that can be used for authorization decision. Local Attribute Authorities may also co-exist with VO Attribute Authorities. Policy Authorities Policy Authorities can provide VO-wide policies that will be evaluated by Authorization Authorities to decide if requests are permitted or not. Local Policy Authorities may also co-exist with VO Policy Authorities. Authorization Authorities Authorization Authorities can make decision on access rights for requests based on attributes and policies that applied to the requests.

Lifecycle of VOs A VO has the following lifecycle... Create to create a new VO Trust Management to manage trust relationships regarding authorities participating to a VO Identity Management to manage federated identities of users in a VO Operation normal status in operation Destroy to destroy a VO in its final stage

Use Cases Use Case 1: Digital Library Use Case 2: Mobile Employee Description Software Configuration Scenario Step 1: School Participation Scenario Step 2: Student access to the Library Extended Scenario 1: Fine Grain VO’s Extended Scenario 2: Contributing Local Library to Public Use Case 2: Mobile Employee (now describing)

Use Case 1: Digital Library (1) A digital library for education material is operated by a public organization called DLEM (Digital Library of Education Materials) Number of schools in the nation participate to the library program The program provides teachers and students to access education materials (Digital Books, Videos, Photos and all other digitally accessible materials for education). There are always some schools newly participating to the program and some leaving from the program. Access Control All the students enrolled in a participant school can have read access to the materials for students. All the teachers can have read access to materials both for students and faculties. Some certified teachers by the participant school also can register new materials. Each school is responsible to its user’s (teachers and students) lifecycle management (registration/removal and other operations) Each school is also responsible to its user's group membership management (bind/unbind attributes to/from students and teachers) The library has special software on the client PC for IP protection which provides appropriate access to the library and prevent illegal copy of the materials. Underlying mechanism between the PC and the library is the Grid Services.

Use Case 1: Software Configuration Client GS Library GS Library VO

Step 1：School Participation Organizations or authorities belonging to organizations establish trust relationships between them. School RO_1 School RO_2 Library RO_L School RO_3 School RO_4 Library VO RO: Real Organization

Step 2: Student Access to the Library Only read accesses to materials for students are allowed School RO_1 School RO_2 Library RO_L School RO_3 School RO_4 Library VO

Option: Fine Grain VO Each school has a separate "agreement" with the library. (That "agreements" are part of the VOs properties) Issue: The library belongs to multiple VO’s VO

Extended Scenario 1：Nested VO’s A group of schools forms a VO (VO_S) and the VO participates in Library VO with other organizations. School VO_S School RO_1 Library RO_L School RO_2 School RO_3 Library VO

Extended Scenario 2: Contributing Local Library to Public One of the features DLEM program provides is that participant school can register their local library to DLEM program so that the contents become available to all other schools The contributor school has to be able to enjoy all the access control and security policy applied to the central library.

Extended Scenario 2： Contributing Local Library to Public School VO School VO School VO School VO Library VO

Extended Scenario 3： Board of Education (VO Attribute Authority) School VO Board of Education Administrative Teacher School VO School VO Library VO Administrative Teacher can remove any materials

VO Security Services Each VOs have a set of Security Services Each Security Services are responsible for providing various services to users or resources belonging in the VO. Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity School RO_2 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity

Scenario 1: VO Management Lifecycle of a VO. VO Manager creates a VO Security Services that represent a VO. VO Manager registers organizations (ROs/VOs) to a VO to establish trust relationships between these organizations (ROs/VOs). Issue: Not sure between which trust relationships are established ... VO Manager registers users and resources of VOs as members of the VO. VO Manager destroys the VO. VO Manager VO Manager manages lifecycle of a VO. It seems like a "role" that is associated with every VO. The identity that created the VO automatically assigned the role, VO Manager. VO Manager can assign others as VO Manager.

Scenario 1-1: VO Creation Request Scenario: A user requests a VO Factory Service to create a new VO. Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (2) create a new Virtual Organization School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (1) invoke createService Possible VO Manager

Step 1: Authorization Decision on VO Creation VO Manager invokes the createService operation of a VO Factory. The VO Factory ask for its access rights to Authorization Decision service. Authorization Decision service make decisions on its access rights based on policies any user can be create a VO ... only certain users is allowed to create a VO ... Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (2) authorize the request (3) ask for the attribute and policies School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (1) invoke createService Possible VO Manager

Step 2: Creation of VO Security Services Once the creation of a VO has been permitted, new VO Security Services that manage the new VO are created. A user who request the creation of VO automatically become the VO Manager of the VO. Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (2) create a new Virtual Organization School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (1) invoke createService VO Manager

Scenario 1-2: Trust Management A new VO has been created. VO Manager configures trust relationships between the existing organizations (VOs/ROs) and the new VO. Library VO Trust Relationship Trust Relationship School RO_1 School RO_2

Step 1: Authorization Decision of Trust Management Trust relationship management between organizations (VOs/ROs) is requested by VO Manager. Trust Management service asks for its access rights to Authorization Decision services. Only VO Manager or some certain user can configure trust relationships. Ask for an authorization Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity Ask for an authorization (1) requests to establish trust relationships School RO_2 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity VO Manager (1) requests to establish trust relationships

Step 2: Establishment of Trust Relationship Trust relationship is established... Issue: The meaning should be drilled down... Is it a kind of policy that will be managed by Trust Management services? What kind of policies exists for the trust relationships... What kind of services rely on such policies... Further discussions needed around this area... Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership (1) establishes trust relationship School RO_2 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership VO Manager

Scenario 1-3: VO Identity Management Their is a virtual organization "Library VO" and organization, "School RO 1". Trust relationship between " Library VO " and " School RO 1 " has been established. The VO Manager of " Library VO " is about to manage federated identity that is going to participate in " Library VO " Identity "service_a@School RO 1 " is registered to " Library VO " Attributes may be assigned to the federated identities. Those teachers who contribute teaching materials to the library may be assigned as "Contributor" ...

Step 1: Authorization Decision on Identity Management VO Manager registers identities to Identity Management services Local managers of organizations may be assigned as Identity Managers to register their own identities to the VO (2) check for the privilege of the requestor Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Identity (1) requests to add "service a" as a member School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership service a VO Manager

Step 2: Membership Management service_a@School_RO_1 exposed as (service_a@School_RO_1)@Library_VO user_1@School_RO_1 registered as a user_1@Library_VO user_1@Library_VO may be assigned as "Certain Certified Teacher" by Attribute Athority, "Board of Education@Library_VO" Federated Identities also bound to local attribute managed by local admiministrators Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership service a user 1 (1) requests to add "service a" as a member School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership service a VO Manager

Scenario 2: A Service Invocation in a VO Context "service_a@School_RO_1" and "service_b@School_RO_2", each belonging to a different real organization, both take part in a same virtual organization, "Library VO". "service_a@School_RO_1" is about to access materials provided by "service_b@School_RO_2" . Authorization is enforced on "service_b@School_RO_2" side based on VO attribute, "Elementary School Student in Library VO", bound to "service_a@School_RO_1". In some cases, some local policies of "service_b@School_RO_2" also enforced to the request. Only students elder than 12 years old can access "service_b@School_RO_2" Various patterns are exists Attributes or polices applied to the requestor may be called a VO/RO context... service_a service_b (1) service request Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership School RO_2 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership

Step 1: Mutual Authentication Identity of "service_a@School_RO_1" and "service_b@School_RO_2" authenticated Some attributes are also bound to "service_a@School_RO_1" or "service_b@School_RO_2" . service_a service_b (1) service request VO Context Attribute Policy VOGSH VO-GSH (Attribute) (Policy) (1) authenticates the service (1) authenticates the requestor Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership School RO_2 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership

(2) ask for attributes and polices Step 2: Authorization The service ask for authorization of the request The service can find appropriate Authorization Decision service by the VO Context bound to the request The Authorization Decision service ask for attributes and policies regarding to the request and the both ends, and make decision on its authorization service_a service_b VO Context Attribute Policy VOGSH VO-GSH (Attribute) (Policy) Library VO VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership (2) ask for attributes and polices School RO_1 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership School RO_2 VO Factory Authorization Policy Attribute Decision Trust Management Authentication Membership

the END