...
| Attribute | Description |
|---|---|
| urn:oid:2.5.4.10 | Organization name |
| dk:gov:saml:attribute:CprNumberIdentifier | Required from SEB. Civil registration number (CPR) |
| dk:gov:saml:attribute:CvrNumberIdentifier | CVR number |
| dk:gov:saml:attribute:RidNumberIdentifier | RID number from certificate |
| dk:gov:saml:attribute:AssuranceLevel | AssuranceLevel (must be 4) |
| urn:oid:2.5.4.3 | Required from SEB. Common name (full name) |
| urn:liberty:disco:2006-08:DiscoveryEPR | IDCard |
| dk:healthcare:saml:attribute:HasUserAuthorization | A boolean saying if the user has any healthcare authorizations |
| dk:healthcare:saml:attribute:UserAuthorizations | A list of the users healthcare authorizations |
| urn:oid:0.9.2342.19200300.100.1.1 | Required from SEB. The globally unique ID of the user within his/her organization. (also known as UID) |
| dk:gov:saml:attribute:Privileges_intermediate | Required from SEB. A base64-encoded XML structure in OIO BPP format, listing privileges. If an employee should have any permissions, this attribute should define one or more roles in scope of an organizational unit or careteam, e.g. a SOR number, STS Organisation or careteam reference. See general structure in documentation[1]. [1] https://digst.dk/media/19020/oiosaml-basic-privilege-profile-1_1.pdf |
| dk:healthcare:ehealth:saml:attribute:scopingOIOBPPContext | Optional. Can be used to limit scopes expressed in the OIO BPP structure, by adding it as a constraint in each PriviledgeGroupPrivilegeGroup. Only PriviledgeGroups with the constraint matching the value of scopingOIOBPPContext will be available for the user. The use of scopingOIOBPPContext is not yet used and will be ignored. Can be used to support multi affiliation in the future. |
...
The OIO BPP snippet above is listed for Practitioner 1 - Lasse Dam. This OIO BPP states that Lasse Dam has the role "urn:dk:sundhed:ehealth:role:monitoring_responsible" in the careteam identified by "95c7aef7-ec7f-487b-9687-6e6624d25fdb" in the organization "440711000016004". If this was the only content of the OIO BPP, Lasse Dam would have been handed a JWT by the infrastructure where the stated careteam and organization would be set in context. Had there been multiple PriviledgeGroups PrivilegeGroups in the OIO BPP, nothing would have been set in context as the choice would not be straight forward for the AS to pick, instead the client would have to ask the user to pick among the available allowed contexts (see Switching Context).
...
Had the example instead looked like the example stated above, the user Lasse Dam would have been issued a more narrow JWT as nothing would have been set into context as the AS would be unable to choose between the whether the user should be in the context of the careteam with the role "monitoring responsible" and "treatment responsible" or in the context of the organization with the roles "clinical administrator" (capable of managing PlanDefinition and ActivityDefinitions) and "questionnaire editor".
The PriviledgeGroups PrivilegeGroups provided in the OIO BPP must be unique in accordance with the following scheme:
...