260 likes | 350 Views
Grid Authorization Landscape and Futures. Von Welch NCSA vwelch@ncsa.uiuc.edu. Outline. Grid Authorization Goals Where would we like to be… Current Grid Authorization Where we are… Future Grid Authorization How are we going to start getting there…. Delegate. Delegate. Delegate.
E N D
Grid AuthorizationLandscape and Futures Von Welch NCSA vwelch@ncsa.uiuc.edu
Outline • Grid Authorization Goals • Where would we like to be… • Current Grid Authorization • Where we are… • Future Grid Authorization • How are we going to start getting there…
Delegate Delegate Delegate Grid Authorization “Flow” VO User Resource Process
Without Common Infrastructure Policy DB
Delegate Delegate Delegate Current State of Grid Authz VO User Enforcement Process
Current Resource Owner to VO • Resource owner trusts an attribute authority run by the VO • E.g. VOMS, CAS • Trust instantiated through key pair user by the attribute authority • Trust may be scoped • More in enforcement…
VO to User • VO Attribute authority issues assertions to users • Attributes are limited by ability of enforcement system to understand them • Today mostly group/role (VOMS) • Some capabilities-based systems emerging (PRIMA, VOMS, CAS)
User to Process • User may delegate rights to processes to allow them to run on their behalf • X.509 Proxy Certificates • Again granularity of delegation limited by ability of enforcement system to understand • Today mostly all or nothing • Some basic limitations • E.g. Allowed to run job?
Resource Enforcement • All of the ability to do delegation comes down to here, where it must be understood • Vanilla GT understands simple delegation (all/nothing/job run), no attributes • Modifications have emerged • VOMS has attribute capabilities for GRAM • CAS in GridFTP with file capabilities • Modifications are painful as must be made to each application and protocol
Resource Enforcement • Some richly features authorization decision systems exist in Grid community • Akenti, PERMIS • Many other in the world • How do we tie these into GT? • Painful process of defining enforcement points, interfaces
GT2 Authz Callouts • Extensions to GT2 to allow basic and GRAM authz callouts (dynamic libraries) • Basic just allows for user, service • Doesn’t understand application - no operation • Good for user-based ACLs, revocation, etc. • GRAM has user, operation (RSL), service, job state • Application-specific changes • Success in initial deployments • Enough to show the track looks promising
Future of Grid Authz • How does OGSA help? • How do we get big, smart enforcement systems? • Can do any policy or delegation the enforcement system understands it
How does OGSA help? • SOAP-based protocols allow for carrying of credentials outside of application protocol • Solves protocol problem of how to pass assertions around generically • Don’t need to hack every application protocol
How does OGSA help? • Web services define common scheme for service interface (WSDL) • Well-defined name for the service • Well-defined names for the operations • And arguments • Allows a policy to talk about “Operation X on service Y” without knowing anything about the service
OGSA Service Authz • This, combined with hosting environment programming model, allows application-agnostic authorization separate from application • Hosting environment can peel off credentials and determine request and outsource authorization • Now possible to write one authz service that understand whatever credentials and policy is needed for a resource
Request O2() Yes No, Reject Can U1 envoke O2 On S1? OGSA Service Authorization HostingEnvironment Service S1 Application Logic User U1
OGSA-Authz • Standard protocol being worked on in GGF by OGSA-Authz working group • Allow for any authz service and resource to talk • As well as standards for attributes so authz service can understand attributes of requestor • Still to be seen how much policy is total application agnostic and can be expressed on user/service/operation
What about WS Security Standards? • WS-Security OASIS TC • Profiles for carrying credentials in SOAP • In looks close to being done • 36 companies have agreed how to send username and password over the wire…
WS Security - SAML • SAML • Attribute assertions look fairly stable • In use (Internet2 and others) • Future of authorization is up in the air, may be subsumed by…
WS Security (cont) • XACML • Good basic language for expressing rights • But, no way to express right to delegate • Can give rights to VO but doesn’t allow VO to delegate rights to user nor user to process • Defines start at a authz protocol, will finish?
WS SecurityCurrent/proposed WSS-specs WS-Secure Conversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security In progress SOAP Foundation proposed promised
WS-Privacy WS Security(confusing picture) WS-Authorization WS-Federation Liberty Alliance XrML WS-Secure Conversation WS-Policy-* WS-Trust XACML SAML WS-Security standardized In progress SOAP Foundation proposed promised
Questions • Where does privacy fit in Grid authorization? • Do science grids care? • Multiple credentials? • When will we need them? • How does one do least privilege delegation with late-binding jobs? • If we leave it up the users, I think we’re in trouble
More Questions • More features tends to lead to more complexity, which leads to errors. Where to stop? • Probably not close yet • How fine grained does authorization need to be? • What information is useful? Arguments, application state, user creds • How to pass this around reasonably? (Might be huge) • How do you authorize “Give me all the database rows I have access to” when authorization is outsourced?