Why doesn't an IdP release (an) attribute(s) to our service?

If you require some attributes, you should request for them.

In Haka, IdP's are required to maintain attribute release policies. Only those attributes necessary to SP's should be released. In Haka this is achieved so that SPs indicate through the metadata which attributes they require. IdPs can configure their attribute release policy using the AttributeInMetadata type (https://wiki.shibboleth.net/confluence/x/dAInAQ) in the attribute filter policy configuration. Basically, if you don't request for an attribute, you will not get it. There are exceptions to this rule.

Safe harbour

Please make note that the Safe Harbour practise doesn't apply after CJOU (Court of Justice of the European Union) found it invalid. Special measures are needed to release personal data out of EEA. The following description about safe harbour is obsolete.

According to finnish personal data act, identifying personal data cannot be released outside EU or EEA (The European Economic Area) unless the recipient conforms to EU's Safe Harbour directive. A list of certified Safe Harbour companies can be found from: https://safeharbor.export.gov/list.aspx.

Opaque, unidentifying attributes can be released without the need to comply with Safe Harbour.

Who should register a service to Haka

While considering a correct registrant, one should inspect, who is responsible for the personal data and the person registry of the service. Which organization will put up the service? By whom the service is run? Who owns servers running the service and where are they located?

The service may already be accessible to Haka users without the need to register it directly to Haka. See: Partner federations.

Signing of the authentication request

The SAML 2.0 Web SSO -profile of Haka is based on the common SAML 2.0 profile of the Finnish public sector.The profile states that: "Service Providers MUST sign the Authentication requests." Shibboleth software doesn't sign the authentication request by default. Signing may be configured in shibboleth2.xml file by defining attribute "signing" to value "true" or "front" in "ApplicationDefaults"-element.

Signing of authentication request in shibboleth2.xml
<ApplicationDefaults entityID="https://testsp.nonexistent.tldn/shibboleth"
                     REMOTE_USER="eppn persistent-id targeted-id"
                     signing="front" encryption="false">

What are the usual details that need to be filled to Resource Registry when adding a service provider to Haka?

  • The entityId should be unique and it should refer to the organization registering the entity. It is also recommended that the entity id is in form of URI.
  • The Service Name should specify a localized name fit for display to users. Such names are meant to allow a user to distinguish and identify the entity acting in a particular role. The content of this element should be suitable for use in constructing accessible user interfaces for those with disabilities. It should also describe the service, not the registree.
  • The Description element specifies a brief, localized description fit for display to users. This SHOULD be a description of the service being offered. The description should be written so that even a person with no earlier connection to the entity could understand why the entity exists.
  • It is recommended that both, the name and the description were in all three languages: in finnish, swedish and in english.
  • Two types of contacts should be specified: technical and support. Support contact is responsible more of the content of the service where technical contact is reponsible for the SAML2-layer.
  • In Haka, only HTTP-POST assertion consumer service is needed.
  • If the service is reporting support for the Single Logout (SLO), there are additional measures that the service will need to support. If unsure whether the service supports the SLO or not, it should not be advertised.
  • If the service is requesting identifiable attributes, it must report a URL to privacy policy document. The document should be accessible in internet to everyone.
  • If the service relies on central Haka discovery service, the discovery response location URL should be reported.
  • It is recommended to report the service login page URL.
  • Attribute requests should be supplemented with a description why the attribute is necessary for the service.
  • The common name of the certificate should correspond to the dns-name of the service.

What is the entityID and where can we get it?

EntityID is defined in SAML-specification for SAML metadata (section 2.2.1) and further in SAML core (section 8.3.6) as:

The simple type entityIDType restricts the XML schema data type anyURI to a maximum length of 1024 characters. entityIDType is used as a unique identifier for SAML entities. See also Section 8.3.6 of [SAMLCore]. An identifier of this type MUST be unique across all entities that interact within a given deployment. The use of a URI and holding to the rule that a single URI MUST NOT refer to different entities satisfies this requirement.

General Haka-practice is that the entityID is in form of an URL that the registree has registered for itself. URL doesn't need to resolve in public Domain Name System (DNS), but the registree has to be able to indicate possession or rightful ownership to the name. Usually the URL is in the general domain of the registree i.e. the same domain the registree is present in the World Wide Web (WWW) of the Internet. The URL should be chosen so that it is persistent in the long term (does not change without strong reasoning) and there is no risk of collision with other services that might be introduced in the future.

The entityId should not change in the change of the host or platform that the service is provided on. Therefore strong consideration should be given for the fact whether the entityId should be chosen directly according to the actual name of the service provider host machine or platform.