[cap-talk] SAML authorizations - capability big picture (was: roles at 'access time')

Karp, Alan H alan.karp at hp.com
Wed Feb 27 18:15:46 EST 2008


Jed wrote:
>
> Regarding the "capability big picture", it seems to me that
> an effort like your SAML work is an example of capabilities
> where "the rubber meets the road".  Namely, dealing with
> network standards for something like a 'Security Assertion
> Markup Language' would seem to eventually be necessary for
> any sort of widespread acceptance and use of the capability
> paradigm for network access control.
>
Our reference implementation follows the existing standard.  We just use it in a different way.  What's needed to get acceptance is to build what we do into the tool chain.
>
> I notice there isn't much (any?) discussion of your
> SAML assertion sorts of capabilities on cap-talk.
> Are the issues relating to communication of such
> permissions discussed elsewhere?  If so, where?
>
We presented the work at RSA 2007 and published a paper on it in November at the ACM Workshop on Secure Web Services (SWS'07).  I'll be presenting "Solving the Transitive Access Problem for SOA" at RSA 2008, and I'm working on a paper on that topic when I'm not reading this list.  On the other hand, Tyler covers his ears every time I utter the word "SOA."
>
> I'd be quite interested to see a paper/talk
> (e.g. for our capability workshop?) on a high
> level overview of modern capability use - even
> one that 'just' focused on the network area (e.g.
> your SAML work, WebKeys, Caja, wideword, E/* vats,
> others?).  Who do you think might be in the best
> position to write up such an overview (don't be
> shy)?
>
"Not me.", said the little red hen.  It needs to be someone up on the literature.  Probably someone who recently wrote a Ph.D. thesis.  It should definitely be someone working on Caja, the implementation likely to have the largest short term impact.  Maybe someone, who like the monks in the dark ages, kept the ancient knowledge alive by developing a programming language with a single-letter name.  Any thoughts on who might meet those criteria?

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp



> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Wednesday, February 27, 2008 1:27 PM
> To: General discussions concerning capability systems.
> Subject: [cap-talk] SAML authorizations - capability big
> picture (was: roles at 'access time')
>
> On 2/27/2008 8:49 AM, Karp, Alan H wrote:
> > Jed wrote:
> >> ...As you refer to the "capabilities" as SAML assertions, ...
> >>
> > ...In our reference implementation ... we make the service
> > arguments be the SAML authorization assertions that delegate
> > rights to the invoked service.  That combines designation
> > with authorization and supports delegation as a message
> > parameter.  To me, that's a capability.
>
> Sounds like it to me.
>
> > In the case where we don't control the application API,
> > we have to pass the delegating authorization assertion
> > in the SOAP header.  We're still delegating in the invocation
> > message, but it's not as a parameter, and the designation
> > is split in a way that requires care to avoid confused deputy.
>
> The above sounds like a mechanism that could be of concern
> to the many capability purists on this list.  Without more
> background on the motivations though, it's difficult to
> get an idea how well that approach meets its design goals.
>
> > One more point.  To me Horton is a means to do some things
> > with just object capabilities that are done differently in
> > other systems.
>
> Sure, the Horton E and Java reference implementations that
> MarkM did are just there as examples of as 'pure' OCap
> implementations of the concepts as he could imagine.
> How/if the basic Horton concept (access tokens sent
> in messages that get relabeled with an additionally
> noted 'delegation' between identities as the pass
> from one subject to another) shows up in production
> implementations remains to be seen.
>
> It's only natural though to compare any production
> implementations with the 'ideal' - that's what reference
> implementations are for.
>
> > For example, our SAML approach doesn't need the stubs
> > and proxies.
>
> Easy to understand.
>
> > In addition, the full responsibility chain is carried
> > in the SAML assertions.
>
> Interesting.
>
> > We also don't need sealers and unsealers because the
> > public keys are visible at the application layer.
>
> Makes perfect sense.
>
> >> Whew.  The above introduces another subject (distinguishing
> >> as it does between the "requester" and the "responsible party"),
> >> but I'm still not sure I understand the statement.  Are you
> >> saying that the important thing is to use the role of the
> >> ID that object access has been delegated to (the "responsible
> >> party") as opposed to some ID that the message came from (the
> >> "requester")?
>
> > The capability was delegated to the Alan who.  Alan delegated
> > that right to Jed, bypassing Horton.  Jed invoked the capability.
> > Jed is the invoker, but Alan is the responsible party.  In an
> > RBAC scheme, Jed's role would be checked.  In a Horton system,
> > only Alan's is.
>
> I believe I understand.  In the RBAC scheme the system has an
> independent knowledge of the "who" for any request.  Independent
> of the access token that is invoked.  Using such identity
> knowledge independently of the access token can of course lead
> to all sorts of problems (separation of designation from
> authorization not the least).  I guess that's what you meant by:
>
> > The important thing is to avoid using the role at access time.
>
> ?
>
> Regarding the "capability big picture", it seems to me that
> an effort like your SAML work is an example of capabilities
> where "the rubber meets the road".  Namely, dealing with
> network standards for something like a 'Security Assertion
> Markup Language' would seem to eventually be necessary for
> any sort of widespread acceptance and use of the capability
> paradigm for network access control.
>
> I notice there isn't much (any?) discussion of your
> SAML assertion sorts of capabilities on cap-talk.
> Are the issues relating to communication of such
> permissions discussed elsewhere?  If so, where?
>
> Do you think of cap-talk as something of an ivory
> tower (whether properly or improperly?) where more
> or less 'pure' capability concepts are discussed,
> but where real world issues are generally excluded?
> Is there another more practically focused center
> of communication about practical application of
> capability approaches?
>
> I'd be quite interested to see a paper/talk
> (e.g. for our capability workshop?) on a high
> level overview of modern capability use - even
> one that 'just' focused on the network area (e.g.
> your SAML work, WebKeys, Caja, wideword, E/* vats,
> others?).  Who do you think might be in the best
> position to write up such an overview (don't be
> shy)?
>
> --Jed  http://www.webstart.com/jed.
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>



More information about the cap-talk mailing list