Child pages
  • Multi-Context Broker and Bootstrapping AuthN Requirements
Skip to end of metadata
Go to start of metadata

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.

Click here to view the SLIDES

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
  • 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(???)

Concern from Michael Gettes: Please make the authN modules work together nicely on a single page, a la the way Duke already does this.  Don't want it to be a serial process with different pages asking people to enter in different bits of information.

List of use cases collected:

Use to enforce criteria for authentication LoA. E.g., have you taken training? Before trusting an account across two systems (they are looking to define this as a context).

Flagging accounts for greater authN requirements independent of SP requirements, for various reasons (account compromised in some way - subject to phishing, etc.)

Enforcing coarse-grained RBAC on SPs from the IdP, to require various SPs or sets of SPs to only work with specific requirements met by the user (confluence of authN and authZ) - NOTE: The SPs need to have a really good error handling mechanism because they will get an authN failure back from the MCB if user doesn't meet some requirement that's been configured on the IdP side.

Trusting browsers for long periods of time after a use of an additional factor a la Google.

Defining and requiring local assurance criteria for specific institutional use-cases.

Non-NSTIC-mapped authN requirements for classes of SPs in the federation (example: requiring MFA specifically).

Integrating an existing RemoteUser login handler with a second factor.

Trusting or not trusting specific subnets (require 2FA if not on a specific subnet, for example).

  • No labels