Attribute checking based on sp location

[Eric Goodman]

Eric:
>> Another potential use case which is probably infrequent in Shib
>> deployments, but seems to be generally on an uptick in other areas is
>> implementing least privilege/privilege escalation management. If done
>> during the IdP authentication, the authentication process could allow you to
>> specify the roles that you need for your access; in such a case reauthing at
>> the IdP could end up returning different attributes depending on how you
>> specify your need.

Samuele:
>Yes, basically this. For instance, a /user location could require a user-pwd authn
>because it only allows to check data, whereas an /updateInfo (or /admin) location
>may require otp as it allows to edit and data. In my case, currently the returned
>attribute set may be the same, and I'm doing access control by checking the
>authentication method.

Scott:
>Haven't seen that so much as just step-up, requesting either a new login as presence
>proof or adding the second factor for specific functions. That obviously also fits within
>the OP's scenario, at least in theory. Getting that in place out of the box was the main
>focus of the 3.3 work.

Because I’ve been looking at PAM solutions recently (feel free to send me your comments on specific PAM solutions off list!) I was thinking of a finer-grained access management approach, but in the particular case you (Samuele) describe, it sounds like what you are doing is “step up” authentication (requiring a stronger authentication event), even though it could conceptually be extended into a more PAM-like approach.

(And again I’m largely using this response as an excuse to troll for information/experiences related to PAM solutions…)

--- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161021/cc12da47/attachment-0001.html>