1 / 30

OGSA-WG Security Use Cases Jan 29, 2004

OGSA-WG Security Use Cases Jan 29, 2004. Takuya Mori <moritaku@bx.jp.nec.com> NEC Corporation. Contents. Overview of a VO Use Cases Digital Libraries Security Services Creation of VOs Trust Management Identity Management Service Invocation. user r. user q. user p. user 1. user 1.

medea
Download Presentation

OGSA-WG Security Use Cases Jan 29, 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OGSA-WGSecurity Use CasesJan 29, 2004 Takuya Mori <moritaku@bx.jp.nec.com> NEC Corporation

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

  3. user r user q user p user 1 user 1 user p user 3 user 2 service_b service_x service_c service_z service_a service_y Organization A 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 service_c service_a service_y Virtual Organization Services and Users are exposed in a Virtual Organization barrier Organization B

  4. 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.

  5. 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

  6. 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 • Use Case 2: Mobile Employee • (now describing)

  7. 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.

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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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.

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

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

  16. Attribute Authorization Policy Identity Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy Attribute Authorization Policy VO Factory Identity Management VO Factory Identity Management Authorization Decision Trust Management Authentication Authorization Decision Trust Management Authentication School RO_1 School RO_2 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.

  17. 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.

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

  19. Attribute Authorization Policy Identity Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy VO Factory Identity Management Authorization Decision Trust Management Authentication School RO_1 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 ... (2) authorize the request (3) ask for the attribute and policies (1) invoke createService Possible VO Manager

  20. Attribute Authorization Policy Identity Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy VO Factory Identity Management Authorization Decision Trust Management Authentication VO Manager School RO_1 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. (2) create a new Virtual Organization (1) invoke createService

  21. School RO_1 School RO_2 Library VO 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. Trust Relationship Trust Relationship

  22. Attribute Authorization Policy Identity Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy VO Factory Identity Management Authorization Decision Trust Management Authentication VO Manager 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 Ask for an authorization (1) requests to establish trust relationships (1) requests to establish trust relationships

  23. Attribute Authorization Policy Membership Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy VO Factory Membership Management Authorization Decision Trust Management Authentication VO Manager School RO_2 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... (1) establishes trust relationship

  24. 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" ...

  25. Attribute Authorization Policy Identity Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy VO Factory Membership Management Authorization Decision Trust Management Authentication VO Manager School RO_1 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 (1) requests to add "service a" as a member service a

  26. Attribute Authorization Policy Membership Management VO Factory Authorization Decision Trust Management Authentication user 1 Library VO Attribute Authorization Policy VO Factory Membership Management Authorization Decision Trust Management Authentication VO Manager School RO_1 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 service a (1) requests to add "service a" as a member service a

  27. Attribute Authorization Policy Membership Management VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy Attribute Authorization Policy VO Factory Membership Management VO Factory Membership Management Authorization Decision Trust Management Authentication Authorization Decision Trust Management Authentication School RO_1 School RO_2 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

  28. Attribute Authorization Policy Membership Management VO Context VO-GSH (Attribute) (Policy) VO Context Attribute Policy VOGSH VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy Attribute Authorization Policy VO Factory Membership Management VO Factory Membership Management Authorization Decision Trust Management Authentication Authorization Decision Trust Management Authentication School RO_1 School RO_2 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 (1) authenticates the service (1) authenticates the requestor

  29. Attribute Authorization Policy Membership Management VO Context VO-GSH (Attribute) (Policy) VO Context Attribute Policy VOGSH VO Factory Authorization Decision Trust Management Authentication Library VO Attribute Authorization Policy Attribute Authorization Policy VO Factory Membership Management VO Factory Membership Management Authorization Decision Trust Management Authentication Authorization Decision Trust Management Authentication School RO_1 School RO_2 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 (2) ask for attributes and polices

  30. the END

More Related