| 56 | |
| 57 | == Configuring the MCB to require 2FA based on the SP == |
| 58 | Scott Koranda via shibboleth.net |
| 59 | 2015-04-17 |
| 60 | |
| 61 | to Shibboleth |
| 62 | Hello, |
| 63 | |
| 64 | The MCB can be configured to use an attribute to determine which |
| 65 | authentication contexts are allowed for a user, ie. |
| 66 | |
| 67 | <idms attributeResolverID="allowedAuthContexts" /> |
| 68 | |
| 69 | Further the attribute can be of type "Script" and have a dependency on |
| 70 | other attributes such as the value of isMemberOf from an LDAP query on |
| 71 | the principal. |
| 72 | |
| 73 | Still further, the script can ascertain the SP by making a call to |
| 74 | |
| 75 | peerEntityId = String(requestContext.getPeerEntityId()); |
| 76 | |
| 77 | Is it not the case then the logic in the scripted |
| 78 | "allowedAuthContexts" attribute can be such that it can make a |
| 79 | decision on which authentication contexts be allowed for a user by |
| 80 | combining the user's LDAP record and the entityID of the SP which the |
| 81 | user is attempting to access? |
| 82 | |
| 83 | The mechanism described above would allow for a per-SP/per-user |
| 84 | "configuration", though admittedly it is not particularly elegant....It appears to work well with my sandbox. |
| 85 | |
| 86 | I should add that I am primarily focused on SPs that do not send an |
| 87 | explicit request for authentication contexts. |
| 88 | |
| 89 | Thanks, |
| 90 | |
| 91 | Scott K |