authn vs. authz

John Dennis

Hi Liem:

Thank you for sending out the sequence diagrams, they've been very
helpful. Also thank you for posting the code to a public git repo. The
code looks clean, nicely organized and professionally written. I've been
going through the code to get a better understanding of the overarching
architecture and I've got a few questions.

My first question is an organizational one, I noticed you've been
sending your emails with design information to specific individuals
instead of the aaa-dev list, is there a reason? FWIW I've sent this mail
to both the individuals you've been emailing *and* the aaa-dev list.
Should we be using the aaa-dev list from this point on?

The Framework Overview ( is clear
that authentication (authn) and authorization (authz) are two
independent concepts and derive from independent sources of authority.
This is good, authn and authz should be separate.

But when I look at the code it looks to me as if authn and authz have
been conflated. I draw this conclusion by looking at the fields in the
Claim and Authentication types. An identity claim is something returned
by a trusted IdP (Identity Provider) which attests to the identity and
attributes bound to that identity by the IdP. It appears as if the Claim
type is being used for this purpose in the code. However the Claim type
also includes tenant and role information. An independent IdP will not
(or should not) have information specific to ODL. This is especially
true for roles, only ODL should know what the roles are and which
identities possess those roles. [1]

Perhaps I've misread the code (please correct me) but it looks as if
ClaimAuthFilter via the ClaimAuth.transform() method is supposed to map
from an IdP identity assertion to a Claim object. What is confusing me
is how or why would an external authn assertion know anything about the
ODL roles in order to populate the roles in the Claim object? [2]

It seems to me there needs to be a separate mapping stage which maps
from an identity assertion to ODL specific information such as tenant
and roles. As an example you might want to look at how Keystone handles
the federated case
In the Keystone federation architecture one binds an (IdP, protocol)
2-tuple to a mapping which maps from IdP attributes to those used
internally (i.e. groups, roles, etc.)

Going back to the code and the sequence diagrams shouldn't there be an
IdentityClaim (does not yet exist) which is passed to a mapping endpoint
(does not yet exist) which returns a Claim instead of the
ClaimAuthFilter attempting to assign roles and return a Claim?

Also, I'm not sure why we have the DirectAuth case as a special case
code path and flow. Couldn't the code be simplified if DirectAuth was an
instance of the federated case? Here the internal DirecAuth "toy" IdP
only does username/password authn and the roles are provided by a
mapping? Fewer code paths usually means more robust code.

I'm sure I have a slew of misunderstandings about how the actually code
works :-) Feel free to set me straight.

Thanks again for the great code and excellent diagrams!


[1] Allowing an IdP to attach a role to an identity is a security
concern. You may trust an IdP to authenticate a user but do you really
want to trust that IdP to also claim that user has the admin role in
your service? It may be case that you trust *some* IdP's to assign roles
but that should be configurable and off by default. I suspect the
DirectAuth case is one such example (correct?)

[2] It almost looks as if the authz processing is supposed to happen in
TokenEndpoint.createAccessToken() where the else clause says

// TODO: Support authorization code later...

but if the claim filters are setting the roles (which is my definition
of authz) then what authorization code is going to execute here?

Join to automatically receive all group messages.