Denying users to login based on pattern in multiple auth flows

[Curry, Warren]

I would wonder why you would be stopping this when the account is authenticating instead of in the software event you use to provision the account.     Why allow the provisioning at all if it is not allowable?  Normally account provisioning and management is separate from the authentication authorization mechanism (SHIB in this case)... 

Does not seem like something Shib should be doing..  ?          You may well have a good reason though..  

Whc  

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, January 29, 2016 9:49 AM
To: Shib Users <users at shibboleth.net>
Subject: RE: Denying users to login based on pattern in multiple auth flows

> We have multiple auth flows enabled (RemoteUser|SPNEGO|Password to be 
> exact) and we would like to be able to disallow users whos username 
> matches a list of patterns to login, preferably via RegExps.

That's really more of a function of the login mechanism, but it depends I guess on the user experience you want or need. Anything the IdP could do would be after the fact right now.

> Is it possible to use some kind of Activation Condition? Or Subject 
> Canonicalization?

Well, the condition is too early, you don't know the name there yet.

It wouldn't exactly be normal to use c14n as the gating function, but you *could*, yes, if that step fails, it should fail the overall login flow. But probably not in a recoverable way, of course, it would fail the login process.

I think it probably could be done in a post-login intercept flow, with a Predicate that looks at the resulting name and evaluates it against the login flow inside the AuthenticationResult that's used to satisfy the request, but you do run into the same issues I've been discussing with another poster about authz and exactly how tight a guarantee the IdP provides about an intercept returning an error. I have an open issue to look at existing hook points and determine if we need a tighter approach people can use to build those kinds of rules.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net