1. Resource Registration

Haka Resource Registry is a tool to produce Haka metadata. IdP and SP administrators are able to manage entities to which they have granted access. Access requires approval from the administrative Haka contact of the registrant organisation. Unauthenticated user is able to add new entries, but can't modify or view them. Authentication is based on Haka.

This chapter explains how to add a new Service Provider (SP) service to the HAKA trust network using the Resource Register. NOTE! This guide contains example images. Use your own company information when registering.

1. Go to Resource Registry and select link Add a new Service Provider
    
2. Select Organization Information and fill the information. Apply changes and return.
   
   
   
3. Select SP Basic Information and fill the information. Apply changes and return.
   
   
4. Select SP SAML Endpoints and fill the information. Apply changes and return.
   
   
5. Select Certificates and fill in the information. Apply changes and return.
   
   
6. Select Requested Attributes and fill the needed information. Apply changes and return.
   
   
7. Select UI Extensions and fill the information. Apply changes and return.
   
   
8. Select Contact Information and fill the information. Apply changes and return.
   
   
9. Select Submit SP Description button. The information then goes to the federation operator's approval and will be reflected in federation metadata after it. You will receive email when registration is checked. 
   
   

2. Certificate requirements

Haka certificate policy defines the type of certificates entities must use to secure the exchange of SAML-messages between Haka identity and service providers. This certificate policy does not apply to certificates used by WWW-servers and subsequently by Haka user clients.

WWW-servers may use any certificates what so ever. However, it is RECOMMENDED that WWW-servers use certificates signed by generally known certificate authorities.

Haka recommends the use of self-signed certificates with a reasonably long validity period when processing SAML messages.

For service providers it is recommended to use two separate keys for encryption and signing.

In SAML message exchange certificates are used to sign and/or encrypt messages between identity and service providers. In the SAML use case certificate needs to be applicable to both client- and server-use. This must be taken into account when creating certificates.

The DNS-name of the service SHOULD correspond to the CN (common name) field of the certificate. This requirement prevents using wildcard-certificates (*.domain.com).

Key length

The public key of the certificate MUST be at least 2048 bits of length.

3. More information about HAKA

Information can found from here.