Re: authn vs. authz


Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi John,

I don't suggest hard-coding mapping logics... It should be some sort of JSON mapping file; there just won't be any API for it, unless someone has the bandwidth. For user/role assignment, we use the internal IdM APIs--Peter perhaps can go through that with us at the next presentation.

The direct auth case is an instance of an external IdM
Perhaps, we have a mix-up of words here... What I mean by direct auth is that there is no external IdP (to distinguish from federation which means external IdP).

Liem

-----Original Message-----
From: John Dennis [mailto:jdennis@...]
Sent: Tuesday, June 17, 2014 7:15 AM
To: Nguyen, Liem Manh; Abhishek Kumar; 'Arash Eghtesadi'; Lakshman Mukkamalla; Lenrow, Dave; Mellquist, Peter; Wojciech Dec; aaa-dev@...; Nathan Kinder
Subject: Re: authn vs. authz

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.


--
John

Join z.archive.aaa-dev@lists.opendaylight.org to automatically receive all group messages.