Changing MCB assurance level per SP and by "risk" (source IP)

[David Langenberg]

On Fri, Apr 4, 2014 at 3:52 PM, Rich Graves <rgraves at carleton.edu> wrote:

> > The SP needs to send the "assurance" requirement via the
> AuthnContextClassRef field of the AuthRequest. You can't control on the IdP
> side "SP X requests must do DUO".
>
> Yes, that flow is as expected. I just need to figure out how exactly to do
> that. I will do my homework. I suppose /etc/shibboleth/bindingTemplate.html
> would be too easy?
>

It's even easier than that.  One of my apps uses the /Login initiator when
it wants an elevated session.  For instance, app detects that user tries to
access a resource that requires silver.  We just redirect over to

https://application.host.domain/Shibboleth.sso/Login?authnContextClassRef=http%3A%2F%2Fid.incommon.org%2Fassurance%2Fsilver&target=URL_ENCODED_PROTECTED_RESOURCE

When the user returns, we check to see that
http://id.incommon.org/assurance/silver is the current
AuthenticationContext.  You can also do that via the commands in either the
RequestMap or in Apache's config.



>
> > As for your second question, once again, it's on the Service to say
> "hmm, this user is from Nigeria, I should make them to 2-factor"
>
> Hmm. I agree that the SP, not something like the IdP's relying-party.xml,
> should decide if an SP wants step-up authentication. But I think I want one
> central decision point on "risky" IPs -- and certainly on dodgy
> globe-trotting behavior. Individual SPs, especially third-party SPs, do not
> know what my IdP knows about expected user behavior.
>
> There is already the <idms attributeResolverID> mechanism for forcing a
> *user* to a higher assurance level regardless of SP. Or is that supposed to
> be an inclusive set, and I'm abusing it by making it exclusive? It looks
> like I could make "creative" use of <idms attributeResolverID> pointing to
> an instrumented database or LDAP server. Go ahead and talk me out of that.
>

I'm "abusing" it the same way you are -- forcing a set of users to a higher
assurance.  The intent of that though is to be an inclusive set.  Now, you
may try getting clever with the attribute-resolver & limiting the values
returned based on either the EntityID of the SP or the IP address of the
user, but I'm not sure how that would play out with the IdPs caching of
resolved attributes if the IDMS attribute's values change per
authentication.  That's more of a question for one of the Devs -- Devs?

Dave

-- 
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140404/2313de45/attachment.html