Date: Fri, 29 Mar 2024 10:39:58 +0200 (EET) Message-ID: <730167399.17573.1711701598710@wiki.eduuni.fi> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_17572_1536616500.1711701598709" ------=_Part_17572_1536616500.1711701598709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Request for tender of a service or an application often requires= definitions for ensuring Haka compatibility. This page is a template= for some possible requirements. Proper consideration is needed by a reques= tor.
Haka is a federated authentication infrastructure based on SAML2-protoco= l. In addition to general SAML2 standards Haka has certain Haka specific re= quirements. Haka aims to be as compatible as possible with international id= entity federations but in some cases it is not possible due to local r= equirements.
In some cases it is required that the application allows local user acco= unts in addition to federated identities.
User attributes
Haka user authentication enables transfer of user attributes to a servic= e. User attributes in Haka are defined in FunetEduPerson attribute schema: = FunetEduPerson schema
Application of personal data received as federated attributes and linkin= g that data to local user accounts must always be evaluated per service. In= general when using Haka, services should minimise the amount of locally cr= eated user attributes and rely on federated attributes.
Storing and updating user information in the service must rely on attrib= utes received through Haka.
Users in Haka are identified using one of the available identifiers spec= ified in the attribute schema: FunetEduPerson schema. The most common identifier used is eduPer= sonPrincipalName-attribute. In some cases it is desirable that existing use= r accounts are linked to federated identifiers.
Based on the use case, authorisation can done based on attributes such a= s user name, role, organization or some other user attribute. Similarly mor= e fine grained rights within the service may be based on user attributes.= p>
Authorisation must be based on federated attributes of the user. = p>
User roles of the service must be based on federated attributes.
Each organization in Haka has their own identity provider. This requires= Haka services to have means of directing users to authenticate at their re= spective identity providers. There are several options to handle identity p= rovider discovery.
The service redirects user to a specified single identity provider for a= uthentication
User accounts may be provisioned prior to user accessing the service. Us= ually this means importing users' Haka identifiers to the service.
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.&n= bsp;