[cap-talk] Architectural Choices: How to migrate from IBAC to OBAC = Object-Based Access Control?

[Karp, Alan H]

Jed wrote:
> 
> Certainly as you say, "A capability is an authorization, but an
> authorization is not necessarily a capability."  In particular
> Identity Based Access Control mechanisms like ACLs
> do authorizations, but not with capabilities.  That was
> my basic point.  I believe that to most people the phrase:
> 
> "Authorization Based Access Control"
> 
> doesn't communicate anything.  All access control is
> "authorization based".
> 
As I explain later in my note, I mean something different when I say an
authorization is not necessarily a capability; I mean whether
designation and authorization are combined or separate.  The distinction
between IBAC and ABAC is whether or not the authentication is used to
make the access decision.  In an ACL system, the user's identity is used
to match the request against some data structure to determine whether or
not to honor the request.  The return value is the authorization.  In
SOA implementations, that matching is done in a Policy Decision Point
(PDP) or Policy Enforcement Point (PEP), and the return value is a SAML
certifictate specifying PERMIT or DENY in the authorization field.  The
service is still responsible for properly interpreting that
authorization.  You only see the distinction clearly by separating
authentication from the production of the authorization and the
interpretation of that authorization.
> 
> > The application API might take a filename as an argument, so the
> > programmers will pass the SAML certificate authorizing 
> access in another
> > part of the SOAP message.  That's weaker but better than relying on
> > authentication.
> 
> I'm afraid you lost me in the details of the first sentence above.
> Regarding the second, when you say "better than relying on
> 'authentication'", I assume you mean "identity" authentication?
> 
The WSDL spec says that the argument is a string specifying the name of
the file to be operated on.  If we're not allowed to change the
application, we can't replace that string with a SAML certificate
designating the file and will have to provide the authorization
certificate somewhere else.  This separates designation from
authorization, so the certificate is not a capability.  It is, however,
an authorization that will be honored without authenticating the
requester.
> 
> Perhaps I'm pushing the terminology a bit, but isn't there
> an "authentication" step even in using capabilities for
> access control?  Namely, something (generally either a
> service provider or an underlying TCB) must verify that
> the capability is authentic.  Once that happens then the
> permission granted in the capability can be assumed
> to be correct - authentication and then authorization -
> even with capabilities.
> 
Verifying that the capability is authentic does not involve
authenticating the requester.  In our SOA implementation, we only check
that the certificate is properly signed by the private key corresponding
to the public key that the certificate was issued to.  This key pair can
be one-off, created just for this specific certificate and not tied to
any authentication.
> 
> I know that's what I hear from many computer security
> people for whom the authentication/authorization
> steps are a mantra.  I personally don't want to fight
> that thinking.
  
I agree.  I avoid the problem by separating authentication from
authorization instead of eliminating authentication.  As I say in my
presentations, "Alice authenticates to her domain and gets her set of
authorizations.  She presents the correct one with her requests, but the
service provider only needs to verify the authenticity of the
certificate, not Alice's authentication."

>                 I'd rather just deflect it a bit
> by moving it away from Identity authentication followed
> by Identity Based Access Control (authorization decisions
> based on the authenticated identity - whether using
> policies based on Roles or on Context or ...) to what
> amounts to Object (reference) authentication followed
> by Object Based Access Control - with all the
> corresponding values that are so near and dear to
> us on cap-talk.
> 
Ocaps is a harder sell than the more general concept of capabilities.
Explicit authorizations are more general than capabilities.  I have been
trying to use those differences to find the smallest change needed to
move people from IBAC (and the others) to ABAC.
> 
> I'm trying to bend our terminology so that it will
> make sense to general computer security people who
> aren't steeped in capability phraseology.
> 
That's exactly what I do when I describe Alice submitting the
authorization certificate directly to the service instead of indirectly
via the PDP/PEP.

________________________
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
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp