Skip to content.
|Networking government in New Zealand.
Archive

Archived articles:

See archives for this section
 

Appendix E - Issues for the Future

[ Table of Contents ]

The following items have either been submitted to the OASIS SSTC or are under investigation by the relevant government agency for consideration in New Zealand Government SAML v2.0 deployments.

Signing of metadata

Signing of metadata is not supported by some SAML v2.0 implementations. Situations can also occur where vendor generated metadata will require manual alteration in order to interoperate with other implementations or comply with NZ SAMS. Where metadata is signed and manual correction of the metadata is required the signature may no longer be valid. It is hoped that as SAML v2.0 implementations mature signing of SAML v2.0 metadata will become a requirement for Liberty Interoperable testing and vendor support will mature.

Cross domain single sign-on (SSO)

Support for single sign-on across domains is a requirement for a number of government agency use cases (see Appendix A for example use cases). There is currently no explicit mechanism supported by SAML for keeping a session alive across domains, in order to enable single sign-on.

Possible options that have been suggested include:

  • When attempting to implement cross domain single sign-on utilising SAML v2.0, a polling mechanism utilising the isPassive flag on the SAML <AuthnRequest> could be implemented. The isPassive flags intent is to check if an active session exists on a IdP without user involvement, hence each check to see if a session exists will reset the IdP session time-out.
  • Utilising custom agents provided by some vendor implementations at the service agencies to handle the session keep alive.

Multiple service agency brands within a service provider

Various government agencies have expressed a requirement for providing multiple service brands through a single platform. SAML v2.0 does not provide a facility to support the service branding requirement.

Possible options for supporting the service branding requirement that are under discussion or have been discussed with the OASIS SSTC as extensions to SAML are:

  • Utilising the <AffiliationDescriptor> element to work in a dynamic manner, i.e. potentially allowing each calling service to specify its brand to the service provider.
  • The proposed <RequestedAttribute> element in the <AuthnRequest> could be used to indicate the required service brand. It is currently envisaged that the <RequestedAttribute> element would work in a similar manner as <RequestedAuthnContext>. Do note that the <RequestedAttribute> can also be used to support the dynamic requesting of attributes.

[ Previous | Contents ]