Policy Management for OGSA Applications as Grid Services Lavanya Ramakrishnan

Overview Motivation Architecture Scenarios Implementation Future Directions

Policy requirements The system maybe – a personal IR system – shared IR system Shared services from different domains Various levels security – Method – Service data – Factory Dynamic policy Security should be independent of application logic Tedious to write policy files Persistent queries Grid Query Processor Collection Manager Indexer GridIR – Grid Information Retrieval

PolicyManager Service Architecture Authorization Service Policy Store Policy Cache Fetch Policy Policy Change

Features Separation of duty – Between policy management and decision points – Synchronization of policy – Policy Management is data intensive – Authorization Service is compute intensive – Scalability of functionalities Flexibility – Authorization at various levels Pluggability – Application specific security independent of application logic

Features Dynamic Policy – Policy can be updated through the PolicyManager – Notification passes from the PolicyManager to AuthorizationService Trust between two entities – Reduces exposure of functionality Only Service Owners can change policy Authorization services can access only specific policies Registered services will have access to the Authorization Service – Can be run as secure services Usability – Graphical user interface to write policy

Virtual Organization Discussions - Scenarios Personal Policy Manager and Authorization Service Application Authorization PolicyManager Application Authorization PolicyManager

Discussions - Scenarios Group Policy Manager and Authorization Service Virtual Organization Application Authorization PolicyManager

Discussions - Scenarios Multiple Policy Manager and Authorization Service Application Authorization PolicyManager Authorization PolicyManager Local policies Decision Merging VO policies Policies to merge decisions PolicyManager Dynamic policies based on load, etc. Common policies Local policies to be enforced in the VO

Service Creation Time PolicyManager GUI Client PolicyManagerService Authorization Service OGSA Service Instance OGSA Service Factory Authorization Service Factory Initialize the policy Create service instance Create OGSA service Create Personal Authz service if required Create Authz service Register Subscribe to policy changes Get policy eg: gridmap

Service Call Time PolicyManagerService AuthorizationService OGSA Service Instance OGSA Service Client XACML PDP Call to service Check Authorization Get policy files if required

Policy Representation - 1 … GSH of the service … OperationName

Policy Representation - 2 … Distinguished Name of client … …

Service Data Policy Manager – Subscribe to policy change for a certain service’s policy – Notification data Something has changed in the policy for a particular service Future – Investigate sending the change in policy – Larger problem of data merging on the receiving end – Changed data may itself be huge Authorization Service – Services will be able to subscribe to notification on decision change Useful for long running jobs Need to evaluate risks

Future directions Extend Policy Representation and Management interfaces – Time conditions – Compatible with interfaces from OGSA-Authz WG Performance measurements of the calls Expand architecture if feasible and required – To allow flexibility to launch them as a single service if required – Send “diff” of policy as notification Caching mechanisms Experimenting with combinations of the services

Acknowledgements NASA Virtual Collaborative Center Sousan Karimi, Kevin Gamiel, Jeremiah Morris, Travis Walsh

Interfaces Operation NameInput MessageOutput Message PolicyManager generatePolicyserviceId – xsd:string acl - custom structure Success – xsd:boolean updatePolicyserviceId – xsd:string acl – custom structure Success – xsd:boolean getGridmapserviceId – xsd:stringgridmapFilePath xsd:string getACLserviceId – xsd:stringpolicyFilePath[] xsd:string Authorization registerpolicyMgrHandle – xsd:string - checkAuthorizationContext – clientId, service, operation authorizedValue – xsd:boolean