Description

A "Hub and Spoke" strategy would likely be used by a group of organizations that don't want to (each) run their own IdP.  Examples would be University or Community College Systems, a group of K-12 school districts (either a regional unit or possibly statewide), or a Regional Network Provider running a Hub and Spoke IdP for its constituents.  Additionally, this could be implemented by a vendor providing the service to multiple clients, however, individual client flexibility of the solution is limited.  The IdP is located at the Hub, and users would enter their credentials and select their institution (for authentication) when logging in.  This allows the "hub" to authenticate the user at their institution and obtain agreed upon attributes which would then be passed on to the Service Provider.  Additionally, a centralized User Consent page could also be presented to the user when attempting to access a Service Provider.

Fact Finder

Mark Scheible, MCNC

Example Deployments

There aren't any known deployments in InCommon, however, there are Hub and Spoke variations in some of Europe's smaller countries - WAYF (Denmark), SURFnet (The Netherlands), FEIDE (Norway).  These are used to provide an entire suite of "federation" services.

Support for the Recommended [Technical Basics for IdPs|], including the ability to consume metadata

Since SimpleSAMLphp is frequently used to implement a Hub and Spoke strategy and its variations, these are supported to the extent they’re supported by SimpleSAMLphp.

Support for Attribute Release

Attribute release is supported, however, client or spoke organizations may not have the flexibility to choose which attributes to release individually.  These may be determined by the organization running the Hub IdP or by a consensus of the client organizations.

Support for Entity Attributes/categories (e.g., R&S)

Not currently.

Support for Multiple Authentication Contexts for Multi-Factor Authentication and Assurance

Multiple authentication methods are supported via SimpleSAMLphp, which allows clients with different authentication implementations (e.g. LDAP, CAS, Active Directory, etc.) to exist in the same configuration.

Support for ECP (Enhanced Client or Proxy)

Via a 3rd-party patch to SimpleSAMLphp

Support for User Consent

Yes, and in a Hub and Spoke configuration it can be centralized, allowing use by all user organizations.

Expertise Required

Depending on the implementation, LDAP experience is required as each organization needs to support some method of authentication used by the Hub.  Additionally, some understanding of how the Hub operates and releases (or not) attributes to connected SPs must be understood.

Resources Required

There are two sides of this strategy.  From the Hub Organization side, knowledge and expertise in running an IdP (likely SimpleSAMLphp) as well as being able to configure and support any additional services being provided to the “Spoke” Organizations.  Spoke Organizations might need few resources beyond maintaining their own campus authentication environment.  Spoke SP Organizations (if offered by one of the group members) would likely need to have similar resources to the Hub organization – ability to run an SP, integrated with their service or application being offered to others.

Upkeep and Feeding Required

As stated previously, there is a lot more upkeep required on the Hub side of this strategy than on the Spoke side.  Hub organizations need to keep their Client organizations “happy”, keep their data secure, provide Services that are needed by the clients.

Applicable Environments

The Hub and Spoke IdP Strategy is not likely to be implemented by a single organization (unless via a vendor-provided service), but could be a good solution for small groups of organizations (Higher Education "Systems" as mentioned above), particularly for client organizations (spokes) that have limited resources to run their own IdP.  However, in a fragmented environment it "might" be implemented to allow access to resources where a central common directory (and person registry) does not exist - e.g. undergraduate student directory, employee directory, alumni directory, distance education directory, standalone guest system, etc.

Pros / Benefits

Biggest benefit to the spoke organizations is that the majority of the work is done by the Hub Organization.  Spoke organizations can join with little or no ongoing overhead, once implemented.

Cons / Risks

The Hub organization controls most of the services provided to the client “spoke” organizations and as a result the spoke organizations have less flexibility in attributes released to SPs, or in SPs integrated with the IdP for example.

  • No labels

6 Comments

  1. trscavo@internet2.edu

    This particular "IdP Strategy" appears to be fundamentally different than the others. Indeed, the description refers to a "federation model," not an IdP deployment model (which is what I thought we were investigating in this WG). We may be talking about apples and oranges here.

    Technically, a "hub" is a SAML IdP Proxy, a SAML entity with both IdP and SP components. At the other end of each "spoke" is an ordinary SAML IdP. AFAIK, the latter is the focus of this WG, not the "hub."

    Unless I'm missing something, this strategy appears to be out of scope for this WG.

  2. Mark Scheible (mcnc.org)

    Tom, thanks for your input - I brought this up during the call yesterday, and said I needed to refine the content to focus more on an IdP deployment.  You're correct about the "federation" aspect and as I was capturing some content to add to the template I realized I was dealing with two different scenarios - a hub and spoke federation model (which I agree is out of scope) and a hub and spoke IdP deployment.  I believe the latter definitely fits with our Alternate IdP strategy and could be implemented by University or Community College Systems, Statewide K-12, or as part of a Regional solution.  The use of an IdP Proxy (with both IdP and SP) is probably the best model for this strategy, and if it's restricted to that alone (or even with a Consent component until it's available as part of the IdP) I think it still fits in our Charter.

    1. trscavo@internet2.edu

      As I read the latest version of the Description section, it appears the goal is to avoid having to deploy an IdP at each end entity. Instead, a single IdP will serve multiple organizations. Is that correct?

      If that's right, then this use case is not a "Hub and Spoke" configuration. AFAICT, there is a single IdP (not an IdP Proxy) and so this "IdP Strategy" isn't an alternative strategy at all. It's a straightforward deployment of an ordinary SAML IdP (or one of the alternative deployments already under consideration).

      As an aside, let me ask: Will this IdP assert eduPersonPrincipalName and, if so, what scope (or scopes) will it assert? Is the idea to assert ePPNs with multiple scopes, one for each end entity? If so, that's a new animal in the InCommon Federation, one that we do not support at this time. Just saying.

      1. Mark Scheible (mcnc.org)

        Tom,  I'll defer to your technical knowledge (and certainly InCommon Operations knowledge).  However, I fail to see how this is NOT an Alternate IdP strategy (from a campus perspective at least) any more than the other strategies described that use Shibboleth or SimpleSAMLphp deployed IdPs.  The Hub and Spoke deployment or "Trusted Third Party" (TTP) allows a campus to participate in a federation with an existing LDAP directory that provides local authentication and management of attributes provided to the TTP Hub, running the IdP.  The key difference I think, is that this strategy could be used by an organization that is supporting many campuses or organizations (University system, Community College system, K-12 organization supporting multiple school districts, etc.).

        * Correct - not an IdP Proxy implementation (I'll fix that), and Yes - it would assert ePPN

        I was also thinking we should ADD a Multi-scoped IdP as another strategy for the same purpose, which allows an individual organization or campus to take advantage of an IdP run and supported by another organization.  Unless they've changed, I believe the University of Missouri System is running a multi-scoped IdP for its campuses.

        Lastly, the fact that InCommon isn't supporting a particular strategy at this time shouldn't necessarily disqualify it.  If it's a valid, effective strategy (presumably used elsewhere), then I think we should list it an an option.

        1. trscavo@internet2.edu

          > I fail to see how this is NOT an Alternate IdP strategy

          Well, we don't even have a title yet. I think we already agreed this is not "Hub and Spoke." So what is it?

          > "Trusted Third Party" (TTP) allows a campus to participate in a federation with an existing LDAP directory that provides local authentication and management of attributes provided to the TTP Hub, running the IdP.

          How is this any different than the existing "Outsourced Shibboleth IdP" strategy?

          > we should ADD a Multi-scoped IdP as another strategy

          I don't think this is an Alternate IdP strategy either. It's an ordinary IdP deployment.

          > the fact that InCommon isn't supporting a particular strategy at this time shouldn't necessarily disqualify it

          I never said that. I mentioned scopes in metadata as an aside since this has nothing to do with "an Alternate IdP strategy." The latter is a deployment strategy.

          But to answer your question about scopes, we have numerous IdPs in metadata with multiple scopes. In almost all cases (if not all cases), the IdP represents a system. Sometimes that system is enumerated in the Participation Agreement but not always (since the system participants are sometimes easily verified via third-party data sources).

          What we don't allow is arbitrary scopes in metadata. Scopes are carefully vetted by the RA to be either registered domains owned by the submitting organization or registered domains alluded to in the Participation Agreement (by virtue of listing the participant names).

          1. Mark Scheible (mcnc.org)

            Can't wait for our next call!  ;^)

            1. I never agreed that it wasn't Hub and Spoke - just that I needed to keep it focused on the IdP rather than a "federation model".

            2. It's different from the Outsourced models in that those have a 1-to-1 relationship of campus to IdP, Hub and Spoke have a many-to-one relationship.

            3. Multi-scoped and Hub and Spoke are more system, regional or statewide alternatives to running IdPs for each Campus, with the individual campus not seeing much difference (from outsourced) other than less autonomy in configuration options.

            4. Okay.  I'm not so sure (any more) there's enough of a distinction to separate out "deployment strategies".  All of these are various deployment strategies of a SAML IdP used by a campus.

            5. Not sure anyone is suggesting the use of "arbitrary scopes", and certainly not for un-vetted organizations.

            *** Bottom line is that I think we need the broader group to discuss whether this strategy should be included, whether to add multi-scoped IdPs, or whether to keep it focused only on individual organizations/campuses and possibly "Note" that for systems, regionals, or statewide groups of organizations these other alternative (deployment) strategies exist.  I'm good either way.