The InQueue Federation, operated by Internet2, is designed for organizations that are becoming familiar with the Shibboleth software package and the federated trust model. It is also available as a temporary alternative to sites for which no suitable production-level federation exists. InQueue provides the basic services needed for a federation using Shibboleth:
- maintenance and distribution of participating site description and security files;
- a central WAYF ("where are you from") web site;
- specification of operational procedures and policies, including user data (attribute) definitions; and
- example target and origin sites with which to test interoperability.
Participating in InQueue permits an organization to learn about the Shibboleth software via the experience of multi-party federated access, while integrating its services into the organization's procedures and policies.
The InQueue federation is specifically not intended to support production-level end-user access to protected resources. Organizations operating target sites are strongly discouraged from making sensitive or valuable resources available via the Federation. Specifically, certificate authorities with no level of assurance may be used to issue certificates to participating sites, and therefore none of the interactions can be trusted.
An organization may join InQueue as an origin, as a target, or both. Participants are expected to be authorized representatives of their organization. Internet2 reserves the right to make final decisions about participation in the Federation.
InQueue is intended to serve as a primary federation for an organization only during the period an organization is learning about Shibboleth and federated operations. Upon completion of this period, the organization is expected to join a Federation (or some other management solution) that meets its long-term operational needs.
By joining InQueue, an organization agrees that the Federation can list their name on the Federation web site as a member of the Federation.
In joining InQueue, an organization will make a good faith effort to maintain a web page describing their use of Shibboleth. This page will be linked from the Federation member list.
By participating, origins agree that all attributes sent to targets in the Federation to the best of their knowledge accurately represent information about the authenticated individual accessing the target resource.
Targets agree to dispose of all received attributes properly by not mis-using them, aggregating them, or sharing them with other organizations.
InQueue distributes a set of root certificates for issuers from which server certificates may be obtained to identify InQueue server components. Both targets and origins should have a certificate obtained from one of the authorities below. Additional certificate authorities may be recognized as necessary to support use of both free and common commercial certificates for testing. The list of certificate authorities used by InQueue is:
The InQueue Federation specifies a set of attribute definitions to support basic attribute-based authorization.
- Attribute assertions issued or received by InQueue members including eduPerson attributes should conform to the syntax and semantics defined by the eduPerson 2003/12 specification.
- urn:mace:dir:attribute-def:eduPersonEntitlement
- urn:mace:dir:attribute-def:eduPersonPrincipalName
- urn:mace:dir:attribute-def:eduPersonScopedAffiliation
- If a Federation member sends or receives an Attribute Assertion containing the InQueue policy uri and referencing one of the listed attributes, the syntax and semantics of the associated attribute value should conform to the definitions specified in the relevant IETF RFCs.
- cn
- sn
- telephoneNumber
- title
- initials
- description
- carLicense
- departmentNumber
- displayName
- employeeNumber
- employeeType
- preferredLanguage
- manager
- roomNumber
- seeAlso
- facsimileTelephoneNumber
- street
- postOfficeBox
- postalCode
- st
- givenName
- l
- businessCategory
- ou
- physicalDeliveryOfficeName
- If a Federation member sends or receives an eduPersonEntitlement Attribute Assertion containing the InQueue policy uri and containing one of the listed values, the syntax and semantics of the associated attribute value should conform to these definitions
- urn:mace:incommon:entitlement:common:1
The person possesses an eduPersonAffiliation value of faculty, staff, or student, or qualifies as a "library walk-in".
To join InQueue, origins submit a request to inqueue-support@internet2.edu containing the following information:
- Domain Name of the origin site (e.g., Ohio State's is "osu.edu").
- Complete URL to access the Shibboleth Handle Service at the site.
- The CN (usually the hostname) or the full subject of the HS's certificate's subject. If the certificate is readable by OpenSSL (not keytool), this value can be obtained using the following command:
$ openssl x509 -in <file> -subject -nameopt rfc2253- Complete URL to access the Shibboleth Attribute Authority at the site.
- Any shorthand aliases the WAYF should support for the origin site (e.g., Ohio State, OSU, Buckeyes)
- Contact names and e-mail addresses for technical and administrative issues.
- The URL of an error page that users selecting this origin from the WAYF may be referred to by targets if there is a problem encountered by the target, such as incorrect attributes leading to an access failure. (optional)
- (optional) Briefly describe the organization's planned uses of Shibboleth.
To join InQueue, targets must submit a basic application to inqueue-support@internet2.edu containing the following information:
- The name of the organization
- Contact names and e-mail addresses for techincal and administrative issues.
- The CN (usually the hostname) or the full subject of the SHAR's certificate's subject. If the certificate is readable by OpenSSL (not keytool), this value can be obtained using the following command:
$ openssl x509 -in <file> -subject -nameopt rfc2253- The URL of all SHIRE locations (specified using a shireURL attribute in a Sessions element) set up for this organization, e.g. https://example.org/Shibboleth.shire. Note that the assumption is that access will only occur over the protocol specified by the SHIRE URL submitted (https or http); if there is a desire to listen on both ports, this should be noted in the application.
Once your site is accepted into and added to InQueue, the following configuration parameters must be entered to ensure interoperability and compliance with federation guidelines. Consult the Shibboleth Deploy Guides for further information on these fields and on origin.xml and shibboleth.xml.
4.a. Origins:
The following steps must be undertaken to configure a standard Shibboleth origin configuration to use InQueue. Some steps may vary or may be completed already depending on how origin.xml has already been modified.
- ShibbolethOriginConfig must be modified as follows:
- providerId must be populated with a URI that will be assigned by InQueue when you are accepted into the federation.
- defaultRelyingParty should be changed to urn:mace:inqueue.
- Ensure that AAUrl has been changed to reflect the value sent in with the application.
- Uncomment the InQueue RelyingParty element. If the default providerId as specified in ShibbolethOriginConfig is not the one supplied by InQueue, modify the providerId to match the value assigned by InQueue to this origin.
- A new KeyStoreResolver or FileResolver element must be added pointing to the private key and certificate for use by this origin. See section 4.b of the origin deploy guide for further information.
- Uncomment the FederationProvider element for InQueue.
- OpenSSL must also be configured to use the appropriate set of trusted roots for the issuance of SSL certificates that Shibboleth trusts. For InQueue, this list may be obtained from http://wayf.internet2.edu/InQueue/ca-bundle.crt. This list should then be copied for mod_ssl, which will typically need to be to /conf/ssl.crt/ca-bundle.crt. This list of CA's is not rigorous nor secure and may contain CA's which have no level of assurance or are questionable.
4.b. Targets:
The following steps must be undertaken to configure a standard Shibboleth target configuration to use InQueue. Some steps may vary or may be completed already depending on how shibboleth.xml has already been modified. This guide covers modification of the default Applications element from localhost operation to InQueue operation for simplicity's sake.
- The providerId attribute of the Applications element should be changed to the InQueue-assigned value.
- Ensure that the Sessions element's wayfURL is https://wayf.internet2.edu/InQueue/WAYF.
- Uncomment the InQueue RelyingParty element within the CredentialsUse element.
- Uncomment the FileResolver element with a Id of inqueuecreds. The key path, key password, and certificate path should be modified to match new credentials generated according to section 4.c of the target deploy guide.
4.c. Refreshing Federation Metadata:
Shibboleth 1.2 includes new metadata both for origin sites and for target sites. The origin has the metadatatool and the target uses the siterefresh tool to maintain locally cached versions of various files. Once your site is accepted into the InQueue federation, it is necessary that you periodically update the federation's metadata. This metadata includes information used to identify and authenticate InQueue sites. This should be frequently run by adding it to a crontab to ensure that the data is fresh.
InQueue's metadata is digitally signed, so the first step is to obtain the InQueue signing certificate. It can be downloaded from http://wayf.internet2.edu/InQueue/inqueue.pem and has a fingerprint of:
b4 42 6c 1e 8b 7d 8e b3 68 03 00 e4 c4 57 dd 74 89 f8 9a 80.
The following commands can be used to obtain the federation's metadata for a Shibboleth 1.2 target:
$ cd /opt/shibboleth/etc/shibboleth
$ ../../bin/siterefresh --url http://wayf.internet2.edu/InQueue/IQ-sites.xml --out IQ-sites.xml --cert inqueue.pem
$ ../../bin/siterefresh --url http://wayf.internet2.edu/InQueue/IQ-trust.xml --out IQ-trust.xml --cert inqueue.pemThe origin metadatatool's operation is greatly simplified if a keystore file is downloaded from https://wayf.internet2.edu/InQueue/inqueue.jks and placed in the same directory as metadatatool. After this has been done, the following commands can be used to obtain the federation's metadata for a Shibboleth origin:
metadatatool -i http://wayf.internet2.edu/InQueue/IQ-sites.xml -o IQ-sites.xml -k inqueue.jks -a inqueue
A sample shibboleth target is available for testing newly installed origin sites. New targets can make use of a sample origin, which is listed as "Example State University" on the InQueue WAYF ( Username: demo / Password: demo ).