Multi-Context Broker and Bootstrapping AuthN Requirements -- Salons A-D
TOPIC: Multi-Context Broker and Bootstrapping AuthN Requirements
CONVENER: David Walker, David Langenberg, Nick Roy
SCRIBE: Eric Goodman and Nick Roy
# of ATTENDEES: 50?
MAIN ISSUES DISCUSSED: Introduction to capabilities of the Shibboleth Multi-Context Broker, demo, and discussion of use cases for the MCB
ACTIVITIES GOING FORWARD / NEXT STEPS: Check out the wiki at: https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Broker - contact David Walker for more info, and if interested in contributing authN modules, etc.
Multi context broker
- Slide show
- Question: can the MCB be extended so that the idp tracks requirements, potentially user-selected? I.e., tracking user setting that "I want 2FA for this app"
- Current model, the answer is "no"
- Demo of authentication from u Chicago
- Showed admin interface with setting silver (shows all prerequisites to silver assurance and whether met
- Lots of interest in the Silver status tracking interface, even though off topic for this session/demo intent :)
- Question: Does the assertion classification change the response returned to SPs? I.e., does the IdP release different attributes based on silver IAP status?
- No, assertion response is based on request
- IdP responds to whatever the request is from the sp, idp is just managing the hierarchy
- One campus allows 2factor authn on "unspecified" authn context requests
- Does the MCB get clients closer to supporting 2factor authentication login handler
- Yes, but won't necessarily require generating a login handler
- Allows for non traditional login pages (throwing a screen in front of the user, support of duo)
- Discussion of population to support
- Showed admin interface with setting silver (shows all prerequisites to silver assurance and whether met
- The mcb does not impose authentication modules, but allows requesting of contexts that can leverage multiple authn contexts.
- Discussion of where it's appropriate to manage requirements as part of an authentication vs an authorization event
- Note that failure at the idp (if it's applying authZ type requirements) will generate an error page at the IdP/SP level, which may be ugly
- AuthZ at the IdP level has the issue of creating a contract the idp may end up changing silently
- Is there a separate need to create a standard, self asserted authentication context for e.g., 2fa?
- Is this a potential stepping stone to LoA
- SAML defined a number of them but they don't tell you much
- Question driving at whether these can be improved by defining additional consensus based values(???)
...