MCB SSO not requiring greater authentication methods

[Paul Hethmon]

> On Apr 9, 2015, at 11:27 AM, Ho, PeiQuan <PeiQuan.Ho at tufts.edu> wrote:
> 
> First, I can't say I'm too familiar with Shibboleth or MCB.  But, what we're looking to do is have SPs point to an IDP and then the IDP will choose an authentication method to use for the SP based on a calculated value.  The value is the attributeResolverID attribute which the MCB then uses to determine the authentication method.  Currently this works in cases where the user logs into the SP directly, but when the user does an SSO connection on another SP handled by the same IDP, it does not check whether the authentication level is sufficient enough to log into the SP.  I don't know if the MCB has this functionally, but I thought that was the idea behind it.  Can you please clarify if not, or if there are other ways we can achieve this?

MCB will look up a value for each user based on the resolver configuration that lists the allowed context values for a user. That lookup is a normal attribute resolver process. So the values returned to it will be effectively static. What ever mechanism is used to acquire the value, the only thing it will get from Shib/MCB is the user’s principal identity. Nothing about which SP they are trying to access.

So, let’s say your user receives a value that indicates context values of “password” and “token” are allowed. Typically the initial authentication for the user would have been at the lowest context level (like password), so assume “password” has been satisfied. If the SP requests the “password” context then everything is done and the SAML response is sent to the SP. If the SP doesn’t specify, then they get password as well. If a second SP the user accesses specifies password or does not specify, then SSO works and they get the same context value used. If a third SP says “token” is required, then the MCB will force the user to upgrade their authentication to “token” level.

That’s the basics of what it does. The Shibboleth wiki under the contributions section has several pages on what it does and a list of test cases that might help your understanding.

Paul

-----
Paul Hethmon
Chief Software Architect
paul.hethmon at clareitysecurity.com