Attribute checking based on sp location
SAMUELE RILLI
samuele.rilli at unicam.it
Thu Oct 20 04:59:09 EDT 2016
2016-10-19 15:35 GMT+02:00 Cantor, Scott <cantor.2 at osu.edu>:
>
> I didn't bother asking, but usually that means they're using separate
> accounts.
Not necessarily. In my scenario, different locations require different
authentication methods to require different level of authentication, but
the account could be the same.
2016-10-19 19:08 GMT+02:00 Eric Goodman <Eric.Goodman at ucop.edu>:
>
> 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.
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.
2016-10-19 19:14 GMT+02:00 Cantor, Scott <cantor.2 at osu.edu>:
> > 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.
>
> 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.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161020/62adc57b/attachment.html>
More information about the users
mailing list