Grid Authorization Landscape and Futures Von Welch NCSA

Outline l Grid Authorization Goals u Where would we like to be… l Current Grid Authorization u Where we are… l Future Grid Authorization u How are we going to start getting there…

Grid Authorization “Flow” VO User Process Resource Delegate

Ultimate Goal is Arbitrary Flows

Without Common Infrastructure Policy DB

Current State of Grid Authz VO User Process Enforcement Delegate

Current Resource Owner to VO l Resource owner trusts an attribute authority run by the VO u E.g. VOMS, CAS l Trust instantiated through key pair user by the attribute authority l Trust may be scoped u More in enforcement…

VO to User l VO Attribute authority issues assertions to users l Attributes are limited by ability of enforcement system to understand them l Today mostly group/role (VOMS) l Some capabilities-based systems emerging (PRIMA, VOMS, CAS)

User to Process l User may delegate rights to processes to allow them to run on their behalf u X.509 Proxy Certificates l Again granularity of delegation limited by ability of enforcement system to understand l Today mostly all or nothing l Some basic limitations u E.g. Allowed to run job?

Resource Enforcement l All of the ability to do delegation comes down to here, where it must be understood l Vanilla GT understands simple delegation (all/nothing/job run), no attributes l Modifications have emerged u VOMS has attribute capabilities for GRAM u CAS in GridFTP with file capabilities l Modifications are painful as must be made to each application and protocol

Resource Enforcement l Some richly features authorization decision systems exist in Grid community u Akenti, PERMIS u Many other in the world l How do we tie these into GT? u Painful process of defining enforcement points, interfaces

GT2 Authz Callouts l Extensions to GT2 to allow basic and GRAM authz callouts (dynamic libraries) l Basic just allows for user, service u Doesn’t understand application - no operation u Good for user-based ACLs, revocation, etc. l GRAM has user, operation (RSL), service, job state u Application-specific changes l Success in initial deployments u Enough to show the track looks promising

Future of Grid Authz

l How does OGSA help? l How do we get big, smart enforcement systems? u Can do any policy or delegation the enforcement system understands it

How does OGSA help? l SOAP-based protocols allow for carrying of credentials outside of application protocol u Solves protocol problem of how to pass assertions around generically u Don’t need to hack every application protocol

How does OGSA help? l Web services define common scheme for service interface (WSDL) u Well-defined name for the service u Well-defined names for the operations l And arguments l Allows a policy to talk about “Operation X on service Y” without knowing anything about the service

OGSA Service Authz l This, combined with hosting environment programming model, allows application- agnostic authorization separate from application u Hosting environment can peel off credentials and determine request and outsource authorization l Now possible to write one authz service that understand whatever credentials and policy is needed for a resource

Hosting Environment OGSA Service Authorization Application Logic Service S1 User U1 Request O2() Can U1 envoke O2 On S1? Yes No, Reject

OGSA-Authz l Standard protocol being worked on in GGF by OGSA-Authz working group u Allow for any authz service and resource to talk u As well as standards for attributes so authz service can understand attributes of requestor l Still to be seen how much policy is total application agnostic and can be expressed on user/service/operation

What about WS Security Standards? l WS-Security OASIS TC u Profiles for carrying credentials in SOAP u In looks close to being done u 36 companies have agreed how to send username and password over the wire…

WS Security - SAML l SAML u Attribute assertions look fairly stable u In use (Internet2 and others) u Future of authorization is up in the air, may be subsumed by…

WS Security (cont) l XACML u Good basic language for expressing rights u But, no way to express right to delegate l Can give rights to VO but doesn’t allow VO to delegate rights to user nor user to process u Defines start at a authz protocol, will finish?

WS Security Current/proposed WSS-specs proposed SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-Authorization In progress promised WS-Federation

WS Security (confusing picture) proposed SOAP Foundation WS-Security WS-Privacy WS-SecureConversation WS-Federation WS-Authorization In progress promised SAML Liberty Alliance WS-Trust WS-Policy-* XACML standardized XrML

Questions l Where does privacy fit in Grid authorization? u Do science grids care? l Multiple credentials? u When will we need them? l How does one do least privilege delegation with late-binding jobs? u If we leave it up the users, I think we’re in trouble

More Questions l More features tends to lead to more complexity, which leads to errors. Where to stop? u Probably not close yet l How fine grained does authorization need to be? u What information is useful? Arguments, application state, user creds u How to pass this around reasonably? (Might be huge) l How do you authorize “Give me all the database rows I have access to” when authorization is outsourced?