grid authorization landscape and futures von welch ncsa [email protected]
TRANSCRIPT
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…
Grid Authorization “Flow”VO
User
Process
Resource
DelegateDelegate
Delegate
Ultimate Goal is Arbitrary Flows
Without Common Infrastructure
Policy DB
Current State of Grid AuthzVO
User
Process
Enforcement
DelegateDelegate
Delegate
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
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
HostingEnvironment
OGSA Service Authorization
ApplicationLogic
Service S1
User U1Request
O2()
Can U1 envoke O2On S1?
Yes
No, Reject
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
proposedproposedSOAP FoundationSOAP Foundation
WS-SecurityWS-Security
WS-PolicyWS-Policy WS-TrustWS-Trust WS-PrivacyWS-Privacy
WS-SecureWS-SecureConversationConversation WS-AuthorizationWS-Authorization
In progressIn progress
promisedpromised
WS-FederationWS-Federation
WS Security(confusing picture)
proposedproposedSOAP FoundationSOAP Foundation
WS-SecurityWS-Security
WS-PrivacyWS-Privacy
WS-SecureWS-SecureConversationConversation
WS-FederationWS-Federation
WS-AuthorizationWS-Authorization
In progressIn progress
promisedpromised
SAMLSAML
Liberty AllianceLiberty Alliance
WS-TrustWS-TrustWS-Policy-*WS-Policy-*
XACMLXACML
standardizedstandardized
XrMLXrML
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?