OGSA-WG Interim F2F Meeting Security Feb. 9-10,2004

OGSA-WG Interim F2F Meeting Security Feb. 9-10,2004
Takuya Mori NEC Corp. OGSA F2F Meeting, Feb. 9-10, 2004

Contents Considerations on Issues that were arose in Jan. 29 Tele-con.
Contract between VO and RO Issue on the term "Trust" in grid. VO Lifecycle Issue on a state transition for VO Contract Issue on the term "agreement" VO Hierarchy Concept Issue on the hierarchical use case for VO. References Slides presented in Jan. 29 Tele-con. OGSA F2F Meeting, Feb. 9-10, 2004

Contract between VO and RO
A contract is between VO and a Member RO A User with VO Manager Role can Add/Remove Member RO to the VO with Contract Contract contains Policy how the Resources/Users are mapped to the VO Resource/Users Mapping Policy Examples Straight Mapping All the RO Resources/Users are mapped into the VO Attribute based Mapping Resources/Users with certain Attributes are mapped into the VO Individual Mapping Resources/Users are individually Mapped into the VO by operations user 1 (VO Manager) service_c service_x service_a user p service_y Virtual Organization Contract A Services and Users are exposed in a Virtual Organization Contract B 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 OGSA F2F Meeting, Feb. 9-10, 2004 Organization B

VO Lifecycle (Creation Phase)
Create a VO Initial VO only has a User with VO Manager role Add a Member RO (RO-A) to the VO Resources/Users are mapped to the VO by its Policy Add another Member RO (RO-B) to the VO The VO is ready for integrated Operations for RO-A and RO-B service_x service_y user p service_z user q user r Organization B Contract B service_c service_a Services and Users are exposed in a Virtual Organization Organization A service_b user 2 user 3 user 1 Contract A Virtual Organization user 1 (VO Manager) OGSA F2F Meeting, Feb. 9-10, 2004

VO for Operations barrier
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 OGSA F2F Meeting, Feb. 9-10, 2004

State Transition of VO Create VO add first member RO
add / delete member RO Modify Contract createVO add first member RO NULL initial state operational state destroy delete the last member RO add / delete Resource/User destroy Create VO instantiate an empty VO (i.e. initial state) only an initial user exists with VO manager role add first member RO the VO goes into its operational state add / delete member ROs or Modify contract delete the last member RO for the VO to go to initial sate Destroy VO destroy a VO instance OGSA F2F Meeting, Feb. 9-10, 2004

Contract Contract A contract itself will be made out side of the system. It is made by persons who manage VO or resources, or users themselves. A contract may consist of List of accessible resources Accessible amount or level of service (Contract about service level agreement should be out of scope of the security discussions) etc... Involved parties of a contract would be Users Services (resources) VO (VOMS) / RO (ROMS) A contract is bi-directional between these parties Authorization polices / service level agreements are derived based on such contract and enforced by mechanisms. user_a as a VO member a contract between a user and a VO VOMS Service_q VO a contract about RO membership to VO user_a as a RO member a contract applicable for RO-wide ROMS Service_p RO VOMS: VO Management Service ROMS: RO Management Service OGSA F2F Meeting, Feb. 9-10, 2004

Types of Contract Contract between VO and Member RO defines how the RO participate into the VO Policies how the Resources/Users are mapped to the VO. Authorization polices of services within Member RO against the other VO members. Contract between a user and VO defines VO-wide terms and conditions between a user and VO VO membership of the user Authorization policies of services within the VO against the user Contract between a user and RO defines RO-wide terms and conditions between a user and RO RO membership of the user Authorization policies of services within the RO against the user Contract between a service and a VO Authorization policies of the service against other members of VO Contract between a service and a RO Authorization policies of the service against other members of RO OGSA F2F Meeting, Feb. 9-10, 2004

VO Hierarchy Concept Deny! Deny! University VO Public Library RO
School of Eng. School of Law Deny! School of Biz Deny! University VO University Library Public Library RO School VO Digital Library of Educational Materials VO denotes that the resource is exposed to the VO and available for authorized VO members OGSA F2F Meeting, Feb. 9-10, 2004

VO Hierarchy: University VO Use Case
DLEM VO DLEM VO consists of participant-VO to the program. Libraries contributed to the program are registered to DLEM VO. Thus they can be accessible for all the members within DLEM VO. University VO University VO consists of School VO such as School of Law, School of Engineering, and School of Business, etc... University owns University Library that is available for all University members. That is University Library is available for all the members of each faculty VO. University Library is also available for authorized members of the DLEM VO. School VO School VO has its own library. School library is available for all the School members. School members are managed (registered) in the School VO. School library is also available for authorized University VO members. School library may not be accessible for person out side of the University. OGSA F2F Meeting, Feb. 9-10, 2004

Authorization Service Authorization Service
VO Security Services Each VO has a set of Security Services. Each Security Services to users and resources participating in the VO. VO VO Factory Authorization Policy Attribute Service Management Identity Federation RO VO Factory Authorization Service VO Mngmnt Attribute Authorization Policy Identity Federation RO VO Factory Authorization Service VO Mngmnt Attribute Authorization Policy Identity Federation OGSA F2F Meeting, Feb. 9-10, 2004

Authorization within VO Context
Service Requestor request a service to Service Provider with VO Context. Service Provider asks Authorization Service for authorization decision. VO Context provides enough information to find appropriate Authorization Service. Authorization Service asks Identity Federation Service for Requestor's VO Membership Assertion. Authorization Service asks Attribute Service for Attribute Assertion of Requestor. Authorization Service asks Authorization Policy Service for Authorization Policy. Authorization Service makes authorization decision based on information gathered above and respond it to Service Provider. Service Provider enforces the authorization decision VO VO Factory Authorization Policy Attribute Service Service Management Identity Federation service provider service requestor VO Context Attribute VOGSH VO-GSH (Attribute) (Policy) a. service request b. ask for authorization c. ask for federated identity assertion d. ask for attribute e. ask for authorization policy f. authorization decision response OGSA F2F Meeting, Feb. 9-10, 2004

VO Security Services VO Factory VO Management Service
VO Factory is a factory service for VO (or VO Management Service) It is referred in the subsection 6.2 or OGSA document VO Management Service VO Membership Service VO Policy Service It is referred in the subsection 6.2 of OGSA document Identity Federation Service Identity Federation Service provides VO Membership Assertion of a subject to a requestor. A missing service in OGSA document. Attribute Service Attribute Service provides Attribute Assertion of a subject to a requestor. The standard attribute set and its format is being discussed in OGSA-AuthZ WG now. Authorization Policy Service Authorization Policy Service provides Authorization Policy to a requestor. Its description is being discussed in OGSA-AuthZ WG now. Authorization Service Authorization Service provides Authorization Decision to a requestor. Its service interface is being discussed in OGSA-AuthZ WG now. OGSA F2F Meeting, Feb. 9-10, 2004

Reference OGSA F2F Meeting, Feb. 9-10, 2004

OGSA-WG Security Use Cases Jan 29, 2004
Takuya Mori NEC Corporation Feb. 6, 2004 With some corrections based on the discussions Corrections are made on slide #21 and #25. OGSA F2F Meeting, Feb. 9-10, 2004

Contents Overview of VO Use Cases Security Services Digital Libraries
Creation of VO Trust Management Identity Management Service Invocation OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004 Organization B

Required Functionalities for VO
The following functionalities are required for VO Identity Federation 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. OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

Use Cases Use Case 1: Digital Library 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 OGSA F2F Meeting, Feb. 9-10, 2004

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. OGSA F2F Meeting, Feb. 9-10, 2004

Use Case 1: Software Configuration
Client GS Library GS Library VO OGSA F2F Meeting, Feb. 9-10, 2004

Step 1：School Participation
Organizations or authorities belonging to organizations establish trust relationships between them. School RO_1 School RO_2 Library RO_L Management Service of the VO which may be hosted by Library RO_L School RO_3 Library VO School RO_4 RO: Real Organization OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 may gain some benefits by contributing their resources to the public. Benefit examples: The contributor may gain more service than ordinary participants. The contributor may access resources that are not available to ordinary participants. etc... OGSA F2F Meeting, Feb. 9-10, 2004

Extended Scenario 2： Contributing Local Library to Public
School VO School VO School VO School VO Library VO OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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. OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

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 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" ... OGSA F2F Meeting, Feb. 9-10, 2004

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 OGSA F2F Meeting, Feb. 9-10, 2004

Step 2: Membership Management
exposed as registered as a may be assigned as "Certain Certified Teacher" by Attribute Athority, "Board of 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 OGSA F2F Meeting, Feb. 9-10, 2004

Scenario 2: A Service Invocation in a VO Context
and each belonging to a different real organization, both take part in a same virtual organization, "Library VO". is about to access materials provided by . Authorization is enforced on side based on VO attribute, "Elementary School Student in Library VO", bound to In some cases, some local policies of also enforced to the request. Only students elder than 12 years old can access 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 OGSA F2F Meeting, Feb. 9-10, 2004

Step 1: Mutual Authentication
Identity of and authenticated Some attributes are also bound to or . 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 OGSA F2F Meeting, Feb. 9-10, 2004

(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 OGSA F2F Meeting, Feb. 9-10, 2004

the END OGSA F2F Meeting, Feb. 9-10, 2004

OGSA-WG Interim F2F Meeting Security Feb. 9-10,2004

Similar presentations

Presentation on theme: "OGSA-WG Interim F2F Meeting Security Feb. 9-10,2004"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

OGSA-WG Interim F2F Meeting Security Feb. 9-10,2004

Similar presentations

Presentation on theme: "OGSA-WG Interim F2F Meeting Security Feb. 9-10,2004"— Presentation transcript:

Similar presentations

About project

Feedback