You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Service or application request for tender often requires definitions for ensuring Haka compatibility.  On this page some possible requirements are given but proper consideration must be give

Authentication protocol

Haka is a federated authentication infrastructure based on SAML2-protocol. In addition to general SAML2 standards Haka has certain Haka specific requirements. Haka aims to be as compatible as possible with international identity federations but in some cases due to local requirements it is not possible.  

User authentication must utilize Haka identity federation: https://confluence.csc.fi/x/JoIUAg. The service must include a SAML2 Service Provider component configure to support Haka SAML2-profile: https://confluence.csc.fi/x/m4IUAg

In some cases it is required that the application allows local user accounts in addition to federated identities.

 

The service must support the use of local user accounts. The capability must be available concurrently with Haka.

 

User attributes

Haka user authentication enables transfer of user attributes to service. User attributes in Haka are defined in user attribute schema: https://confluence.csc.fi/x/FoMUAg

Attribute usage and links to local user accounts must always be evaluated per service.  

 

Storing and updating user information must rely on attributes received through Haka. 

Users in Haka are identified using one of the available identifiers. Most common identifier used is eduPersonPrincipalName-attribute. In some cases it desirable that existing user accounts are linked to federated identifiers.

User's Haka identifier must be linked to existing user accounts in the service.

Authorisation

Restricting access to a service is often a fundamental requirement. Based on the use case, authorisation can done based on attributes such as user name or role. 

Users from specific identity providers are allowed to access the service.

Authorisation must be based on user attributes. 

Service use roles must be based on attributes.

Identity provider discovery

Each organization in Haka has their own identity provider. This requires Haka services to have means of directing users to authenticate at their respective identity providers.

Services must weigh in on whether to locally managed discovery or use the centralized Haka Discovery Service.

 

Discovery must be done in service user interface.

 

Discovery must be done using URL address

Centralized Haka Discovery Service must be used

 

The service redirects user to a specified identity provider for authentication

User provisioning

User accounts may be provisioned prior to user accessing the service. Usually this means importing users Haka identifiers to the service.

User accounts are created through management console based on Haka user identifiers. Service is accessible on on first federated login for configured users.

Users may be provisioned as they access the service for the first time. After the user account exists additional rights can be granted to a user. 

User account is provisioned on first federated access.
Access rights can granted through management console.
  • No labels