Page tree
Skip to end of metadata
Go to start of metadata

Jump to: 

Updating Contacts using Federation Manager

Log into the Federation Manager as a Site Administrator(SA).

Click on the entity you wish to update to bring up the View/Edit page.

On the left navigation, click "Contacts" to bring up the Contacts information section. Update contacts as appropriate.

Remember: your metadata is not published to the InCommon metadata until you submit it for publishing using the "Submit This Entity for Publishing" button in the Review and Submit section. When you are ready to publish your metadata, don't forget to press that button.

About Contacts information in the InCommon metadata

Contacts information in metadata enables Federation participants to contact each other to coordinate interoperation set up, support, and incident response efforts. The same information, when displayed as a part of the service's (Identity Provider or Service Provider) profile, also gives the user a way to contact the service operator for support and troubleshooting.

A contact record consists of a name, a type, and an email address.

The InCommon Federation supports 4 types of contact information:

Contact TypeRequiredDescription / Purpose
Administrative Contactrequires at least one

An Administrative Contact handles non-technical, business process related matters. Fellow federation participants and end users contact individuals in this role to address non-technical issues such as attribute release policy, on-boarding issues, privacy, assurance certification and other business operation matters.

Technical Contactrequires at least one

A Technical Contact responds to technical inquiries and incidents such as troubleshooting software, systems, or networking issues. 

To ensure a timely response and continuity, a Technical Contact should point to a technical operations group rather than an individual. 

Security Contactrequired

A Security Contact is your service's security incident response team, or at least the intake point for security incident response. Fellow federation participants contact persons in this role to coordinate security incidents involving federated access.

Support Contactoptional

A Support Contact is the party responsible for end-user support for your service. A Support Contact typically points to the service's help desk.

While optional, it is good practice to include your service's help desk in your metadata so that where appropriate, parties interoperating with you can direct a user to the correct support desk. 

How might these contacts be used?

 Here are a number of hypothetical user scenarios that rely on contact information:

  • A user authenticates successfully at the IdP and is subsequently redirected to the SP. The SP software, seeing that the SAML assertion does not contain the desired attributes, links to the IdP's errorURL location, if available. In addition to displaying a message to the user, the SP software sends a back-channel message to an institutional administrative contact at the IdP, describing in detail the event that just occurred. The message includes a pointer to the SP's Requested Attributes in metadata.
  • A user encounters and reports a technical failure while accessing a service. The SP's support staff determine that the user's IdP is misconfigured (e.g., its clock is off), and informs the technical contact at the IdP.
  • A user encounters and reports a technical failure while accessing a service. The SP's support staff determine that the user's environment is at fault, and assists the user in informing the support contact at the IdP.
  • A user's credential status is downgraded due to password compromise. They reset their password, but can't get to their grant submission site. The SP's support staff determine that the users assurance level is too low and assists the person in informing the support contact of the IdP.

Contacts as expressed in SAML

Contact information is expressed in series of <md:ContactPerson> elements in SAML metadata. Note these rules when working with metadata registered in the Incommon Federation:

  • Each <md:EntityDescriptor> element SHOULD contain at least four contacts. Each contact is expressed using the  <md:ContactPerson> element. Each should have XML attributes contactType="support", contactType="technical", and contactType="administrative", plus a fourth <md:ContactPerson> element with XML attribute contactType="other" respectively. The element with the contactType="other" is the Security Contact, It carries an extra XML attribute indicating the contact is a security contact. See example below.
  • An entity MUST declare a technical contact (contactType="technical").
  • An entity MUST declare an administrative contact (contactType="administrative").
  • An entity MUST declare a security contact (contactType="other"; with an extended REFEDS metadata attribute of contactType="http://refeds.org/metadata/contactType/security".)
  • Each <md:ContactPerson> element MUST contain at least one <md:EmailAddress> element.
  • If a contact is a non-person (such as a mailing list), the <md:GivenName> element MAY contain a title or label, and the <md:SurName> element SHOULD be omitted.
  • If a contact is a real person, the <md:GivenName> and <md:SurName> elements SHOULD reflect the person's real name.


<md:ContactPerson contactType="technical"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:GivenName>Technical Support Team</md:GivenName>
  <md:EmailAddress>mailto:tech_support@example.org</md:EmailAddress>
</md:ContactPerson>
<md:ContactPerson contactType="administrative"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:GivenName>Office of Administrative Support</md:GivenName>
  <md:EmailAddress>mailto:admin_support@example.org</md:EmailAddress>
</md:ContactPerson>
<md:ContactPerson contactType="support"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:GivenName>Help Desk</md:GivenName>
  <md:EmailAddress>mailto:help_desk@example.org</md:EmailAddress>
</md:ContactPerson>
<!-- security contact with REFEDS syntax -->
<md:ContactPerson contactType="other"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
     xmlns:remd="http://refeds.org/metadata"
     remd:contactType="http://refeds.org/metadata/contactType/security">
  <md:GivenName>IT Security Office</md:GivenName>
  <md:EmailAddress>mailto:security@example.org</md:EmailAddress>
</md:ContactPerson>