force termination of SSO session?

[Les LaCroix]

>
> I think the suggestion to use a directory attribute is probably more
> appropriate, and that can easily fail closed if desired.


I haven't looked at the account lockout feature except for skimming the
wiki page.  If it's activated via API, does its state remain across an IdP
restart/reboot?  I also assume you'd have to call the API for every member
of the cluster for it to have the desired effect in an adverse termination
situation; but you know what they say about "assume".  Those aren't issues
for something based on directory attributes.

-Les

<http://www.carleton.edu/>

*Les LaCroix '79*

Strategic Technologist

Information Technology Services

t: (507) 222-5455


On Fri, Jul 23, 2021 at 7:45 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/23/21, 3:16 AM, "users on behalf of Peter Schober" <
> users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at>
> wrote:
>
> >    Would it be possible to have the authn subsystem(s) check back with
> >    the account lockout status in a future release before succeeding?
>
> Lockout is based on the username (and usually a client address) that gets
> passed into authentication and in the stage you're talking about that's
> long gone and is quite likely something completely different in many
> deployments after normalization. Plus since it's generally address
> specific, it's easy to circumvent in exactly the situations an
> administrative logout would be trying to address.
>
> I think the suggestion to use a directory attribute is probably more
> appropriate, and that can easily fail closed if desired.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> 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/20210723/4d8f02ea/attachment.htm>