This section describes what you need to knw in order to change the look and feel of the Discovery Service. To control what is sent to the user interface you should consult DSUserInterface
The look and feel is controlled via a JSP file and an example
wayf.jsp is provided with the standard distribution. This documentation draws on the contents and comments in that file.
Mode specific Beans
The DS can work in two modes. WAYF ("where are you from") or DS (Discovery Service) mode. Although much of the detail available to the jsp is the same in both cases there are a few beans which are specific to each. These beans are usually sent straight back to the DS when the GUI completes.
DS specific beans
These beans are as described in the Discovery Service Protocol.
- entityID The presence of this is used to indicate that the DS is in DiscoverService mode. It should be passed back to the DS as a parameter of the same name.
- returnX This corresponds to the "return" parameter to the DS protocol. It should be passed back to the DS as parameter of the same name.
- returnIDParam This should be passed back to the DS as parameter of the same name.
WAYF specific beans.
The beans are the same as the parameters to the AuthnRequest message. They need to be returned as parameters of the same name. They are
- time (optional)
Example jsp sequence to call back to the DS as part of a
Mode independant Beans
This is the information which the DS provides to the JSP.
- cookieList If this exists it represents the contents of the_saml_idp cookie (possibly filtered to remove IdPs whichcannot serve the SP). It is a Collection of IdPSite objects,which themselves have the following properties:
- name The uri for the IdP, which needs to be returned to the WAYF in the origin parameter.
- displayName User friendly name (taken from its alias)
- addressFor The (ungarnished) URL for the IdP. This could be used to create a direct hyperlink to the IdP
- sites If this exists it contains all the possible IdPs for the SP (possibly filtered). It is a Collection of IdPSite Objects which are described above. This is only present if provideList was defined true in the configuration.
- siteLists If this exists it contains all the possible metadata files which can service for the SP (possibly filtered). It is a collection of IdPSiteSetEntry Objects which have two properties:
- name This is the displayName from the Metadata element in the WAYF configuration file
- sites This represents the IdPs. Again it is a collection of IdPSite Objects. It is only present if provideListOfList was defined true as described in DSUserInterface.
- singleSiteList if this is present, then there is only one IdPSiteSetEntry Object in siteLists.
- searchresultempty If this is present then it means that a search was performed, but no suitable IdPs were returned.
- searchresults If this is present it represents the list of IdPs which matched a previous search. It is a Collection of IdPSite Objects described above under cookieList.
Other parameters the JSP has to pass back to the DS
The jsp communicates back to the DS via the Mode specific parameters listed above, and:
- action what the Ds has to do. Possible contents are:
- lookup - refresh the screen.
- search - perform a search on the contents parameter "string"
- selection - redirect to the IdP with the uri origin
- cache preserve any selection in the _saml_idp cookie. A value of "session" makes the cookie last for the browser session, "perm" gives it the lifetime asd as described in DSUserInterface.
Accessing the metadata extension for login and discovery
As a side-effect of updated the supporting libraries in the V1.1.3 release the DS can access the information described in
<mdui:UIInfo> extensions, as described here
This is relatively complex and requires confidence with Java programming, JSP deployment and a reasonable working knowledge of the OpenSAML support for metadata.
The following describes some “recipes” for accessing this information in V1.1.3.
This information will change in later versions. We expect to have to make substantial alterations to support these changes.
These code segments are provided as is. Remember this is not a supported interface.
Importing the required libraries
The code segment below requires that certain packages are declared:
Locating the MDUI information for the SP
In non-error cases, an object representing the SP is available via the attribute named “providerObject”. The code section below shows how to access the SP, and navigate to find the
<mdui:Logo>. Note that no filtering for size or language is being applied.
Finally, if no name is located, the entity name is inspected to try to generate a “user friendly” display name for the SP.
Locating all available Logos for the IdPs
Accessing other information
This should be a relatively simple extension of the code samples above. Interested parties are encouraged to add to this code page.