Project Resources Wiki
Project Overview
A GUI (Graphical User Interface) is being developed for the Shibboleth IdP, funded by Internet2/Trust and Identity and Unicon and with the guidance of community architects including Scott Cantor, whose initial focus is on managing metadata and metadata filters (using entity attributes).
Why metadata? One of the primary reasons that the Shibboleth IdP is so widely adopted is its ability to leverage metadata, including large metadata aggregates found in many of the eduGAIN member federations, to support large-scale multilateral federated identity. The Shibboleth development team, in accordance with increasing community needs, is expanding the range of behaviors/settings of the Shibboleth IdP that can be controlled through metadata. In particular, as part of the next release of the Shibboleth IdP version 3.4, support is added for entity attributes that can trigger various relying party override settings.
The Shibboleth IdP already supports the ability to craft attribute release (filter) rules that are triggered by entity attribute settings, and other settings (such as NameID ones) can be similarly "activated".
This new Shibboleth UI already enables the Identity Administrator to create Service Provider (SP) metadata files from "scratch", or import metadata for an SP from a file or URL, and add entity attributes to those metadata that may impact relying party settings such as required authentication context, what is signed, signature algorithm, encryption, etc. Moreover, if the Identity Administrator adds the right template to the attribute-filter.xml file, the UI also enables the management of which attributes may be released to that SP. The current work on the Shibboleth UI is now focused on enabling the Identity Administrator to similarly add entity attributes to specific SPs from the InCommon metadata aggregate by creating metadata filters that will "annotate" that core InCommon-provided SP metadata. Through these filters, aspects of the IdP's behavior and how and what is contained within the SAML response to a given SP, can be managed thru the UI.
Further iterations of the Shibboleth UI are planned, which will continue to expand on the range of metadata source and filter types supported thru the UI, and allow defining and managing custom entity attributes. How the UI expands beyond that is a conversation for the community to have as this work moves forward.
Additional resources
Shibboleth Metadata Management GUI - Requirements