Re: authn vs. authz

John Dennis

On 06/16/2014 07:49 PM, Nguyen, Liem Manh wrote:

Hmm... for some reason my email client (Thunderbird) is having trouble
quoting your message in my reply (your text is a single long line that
Thunderbird wants to truncate) so I'm going to do some manual cut-n-paste.

You are correct that the ClaimAuth::transform() maps the identity
assertion into a Claim object. While an external AuthN assertion
does not know anything about ODL roles, the specific ClaimAuth
implementation should know how to extract the external AuthN
assertion information and any additional attributes needed to map
that particular IdP protocol onto ODL roles/domain. Sure, it could
use a mapping service like you mentioned underneath the hood. We
could even have a generic mapping service like Keystone (thanks for
the link, BTW), but to keep it simple for Helium, I am thinking we
can just have a mapping service specific to SSSD, since our goal is
to support SSSD, unless someone has the bandwidth to implement a
generic mapping service/API—which I would be a fan of!
OK, but here is my concern. The ClaimAuth filter is Java code, if I'm
understanding you correctly you're suggesting hardcoding business logic
of how to map external IdP properties into ODL properties. I don't see
how hardcoding that logic is viable.

Suppose the logic is bob@... is assigned the admin role. What
happens when Bob leaves or Sally is added as an admin? Do we have to
edit the Java filter code?

It seems to me the ClaimAuth filter has to rely on some loadable mapping
resource. But once you have the mapping support the game changes, see
below ...

The internal IdM provides 2 main functions: authorization (what
roles does this user have in what domain?) and identity assertion (is
this the user he claims to be with the given credentials?). Direct
AuthN involves both functions of the internal IdM, while the
federated case involves only the first one. Hence, we have 2
separate interfaces to call out these differences. As you can tell,
I am a fan of using separate Java interfaces to enforce/express
contracts J.
If you have a IdM -> ODL mapping facility then you don't need 2 distinct
implementations. The direct auth case is an instance of an external IdM
and you've eliminated a significant amount of code to author and verify
is correct.


Join to automatically receive all group messages.