Next Steps after Signing the Participation Agreement

Once you have joined InCommon (Participation Agreement signed by both sides), the next steps which need to be completed before one can actually register your metadata with InCommon follow. The key is getting the persons who will serve in the role of the campus' InCommon Executive and Site Administrator(s). These roles are described here:   https://www.incommon.org/roles.html


Steps:

  1. In Section 18 of the Participation Agreement, the college/district identified the person who will serve as the initial InCommon Executive. InCommon will establish that it has accurate contact information for that person, so it can verify the submission of any forms by the Executive.

  2. The Executive designates up to two Site Administrators by completing the form here: https://app.smartsheet.com/b/form?EQBCT=6d51f902251f4a038263e53c152fadb3

  3.  InCommon staff will "identity vet" the designated Site Admin(s).

  4.  InCommon will then provide a way for each Site Admin to establish an InCommon Federation Manager login account.

  5.  Create some form of "Participant Operational Practices" (POP) document, where one option is to use the template form here:  https://www.incommon.org/federation/fopp/

    1. The POP is simply meant to be something that, at least at a very high level, says something about how you "do identity management" within the college. The requirement is that a POP exist, not what is in it. The POP could (obviously not ideal :-) say "we have no idea how we are doing identity management", and, technically, satisfy the requirement that a POP exist.

    2. Note this POP requirement is very likely to change in not too long, switching to being a basic affirmation that you have a core process for managing identities, credentials, etc. that is reasonably sound. So, unless you have other reasons (like for your own documentation purposes) to fill out that full template form above, keep your POP simple, perhaps a couple of paragraphs that  speak to why you think you satisfy the following expectations:

      1. Baseline Expectations of Identity Providers
        • The IdP is operated with organizational-level authority

        • The IdP is trusted enough to be used to access the organization’s own systems

        • Generally-accepted security practices are applied to the IdP

        • Federation metadata is accurate, complete, and includes site technical, admin, and security contacts, MDUI information, and privacy policy URL

    3. Put your POP, or at least information on how one can obtain a copy of it, onto a web accessible page and register the URL to that page in the InCommon Federation Manager.

    4. In the Info box at the end of this page is one example of what a simple POP could look like.

  6. You are now ready to register metadata for the college using the nCommon Federation Manager at https://www.incommon.org/federation/siteadmin.html . See the detailed instructions for doing so on the following page: Registering your Shibboleth (or other SAML) Identity Provider with InCommon

  7. NOTE:  there is one more thing that it is useful to figure out before you go to register your IdP. One thing you'll be asked to identify are several types of Contacts. These Contact types are described on this page – https://spaces.internet2.edu/display/InCFederation/Contacts+in+Metadata – but here is the summary (from that page):

    1. Types of contacts:

      • technical contact: for direct communication between InCommon participants regarding technical issues such as troubleshooting software, systems, or networking issues

      • administrative contact: for direct communication between InCommon participants and by institutional users regarding non-technical issues such as attribute release policy, on-boarding issues, privacy, assurance certification and assurance qualifiers, etc.

      • security contact: for direct communication between InCommon participants regarding security matters, especially for the purposes of Federated Security Incident Response

      • support contact: for end-user technical support but may also handle questions from users regarding attribute release policy, user privacy, access issues relating to assurance, etc.

    2. All are important in different scenarios, and participants are encouraged to provide at least one of each type. At least one technical contact is REQUIRED in metadata. At least one administrative contact is REQUIRED as well.

    3. Contact information should be role-based such as help_desk@example.org rather than individual such as janedoe@example.org.

    4. So you will want to plan ahead, before registering the IdP, as to exactly who/what you want to list for each of these contacts.

One example of a simple Participant Operational Practices (POP)

XXXXX College/District has established business processes for creating and maintaining person records in its HR/SIS system(s), and provisioning those users into an institutional directory(ies). The institutional directory(ies) serve as the primary credential and attribute store(s) for the campus Identity and Access Management services, including the (Shibboleth/PortalGuard/Ellucian Ethos) SAML/SSO Identity Provider. (IdP) This directory(ies) and IdP are used for authentication for key college services such as example1, example2, example3.

These directories and IdP are operated by Central IT, under policies established by the college, and are managed under the security practices for critical college IT services.

The college/district will ensure that the metadata registered with InCommon for the IdP (and any SPs if applicable) is accurate, and will be kept current if and as changes are made that would need to be reflected in that metadata.

(If you have have IT and/or Privacy Policies you want to highlight, you could include a link to such documents at the end.)