Re: PassThruAuthNMayHarmInterop

[Evan Prodromou <evan@outlook.net>]

>>>>> "SF" == Stephen Farrell <stephen.farrell@baltimore.ie> writes:

    SF> To give an example, think about a "typical" scenario: using
    SF> the password associated with an LDAP entry to authenticate a
    SF> user and storing some authorization information related to
    SF> that user (there may well be additional authorization
    SF> information elsewhere) in the same LDAP entry.  The decision
    SF> made at the F2F means that both the PEP and PDP
    SF> *independently* have to access the same LDAP entry.

I think you're ignoring the role played by the attribute authority in
the domain model. It seems to me -- and I may be way off here -- that
per our domain model, one sample scenario would go something like
this:

        1. The user passes a user name and password to an entity
           acting as an Authentication Authority -and- as an Attribute
           Authority.

        2. The Authentication Authority checks the LDAP directory to
           assure the correct username/password, and returns an AuthC
           assertion expressing the identity of the user as well as an
           Attribute assertion giving authorization attributes for the
           user (such as group membership, role, etc.), retrieved from
           the LDAP entry.

        3. When trying to access a resource protected by a PEP, the
           user presents the AuthC and Attribute assertions. 

        4. The PEP sends a request message to the PDP asking for a
           decision on the user's authority to access the resource. In
           the message, it includes the AuthC and Attribute
           assertions.

        5. The PDP returns an AuthZ decision assertion giving a yes or
           no on the user's authorization to access the resource.

        6. Based on the AuthZ decision assertion, the PEP allows or
           denies access to the resource.

This seems fairly straightforward and doesn't seem to require passing
the username/password along with the assertions. One problem, of
course, is that the Attribute Authority needs to know -which-
attributes to put in the attribute assertion early on in the
flow. If we presume that the attribute assertion is directed towards a
particular PEP, this is probably OK. However, it's also possible to
have it work without prior knowledge of which attributes the PDP will
need:

        1. User passes user name and password to an AuthC authority.

        2. AuthC authority checks username and password against an
           LDAP entry, returns an AuthC assertion identifying the
           user.

        3. When trying to access a resource protected by a PEP, the
           user presents the AuthC assertions. 

        4. The PEP sends a request message to the PDP asking for a
           decision on the user's authority to access the resource. In
           the message, it includes the AuthC assertion.

        5. The PDP sends a request message to the attribute authority
           for the user, requesting particular authorization
           attributes. It includes the AuthC assertion to identify the
           user.

        6. The attribute authority checks the LDAP directory and
           returns an attribute assertion with the requested
           attributes.

        7. The PDP returns an AuthZ decision assertion giving a yes or
           no on the user's authorization to access the resource.

        8. Based on the AuthZ decision assertion, the PEP allows or
           denies access to the resource.

Note that in step 6, the attr authority does not have the username and
password of the user, so it can't retrieve entries from the LDAP
directory under the user's authority, but instead uses its own
authority to check the attributes. This may be a good or bad thing,
depending on your point of view.

~ESP