ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAH
1
fa
2
TIER Minimal Registry SchemaTIER Minimal Person Schema Example (GaborE)midPoint 3.6 UserTypeCOmanage Registry Data ModelRFC 7643 System for Cross-domain Identity Management Core SschemaCommentsSCIM DefinitionPotential TIER Extensions to SCIM schema
3
4
3.1 Common Attributes
5
Institutional Entity IdentifieridObject IDIdentifier/identifier (type eg 'platform')
(recommendation is to create an autoassigned identifier and not use internal databased keys)
id - The system that produces the SCIM response (server) is authoritative for thisuuid-ish, shareable; may have the same value the internal, permanent identifier (if risk is deemed acceptable)
6
externalId - The system that issues the SCIM request (client) is authoritative for this
7
meta
8
meta.resourceType - resourceType (User, Group,...)
9
dateCreatedIdentifier/created - created
10
Identifier/modified - lastModified
11
- location
12
Identifier/revision - version
13
dateInactivated
14
15
4.1. "User" Resource Schema
16
17
4.1.1. Single-Valued User Attributes
18
Identifiers/userNameidentifiers/userName (TBD)nameIdentifier/identifier (type eg 'uid')userName"username"
19
Entity Data Definition/"Entry Description / Name"friendlyName (originally entryName)
NAName/* (primary? type=preferred?)
(up to exporter/provisioner to format if desired)
name-formatteda friendlyName,
an ldap-ish common name,
a human-displayable name
suitable for UI purposes
20
NANAassignmentsWhat is an "account" in this context?NAAccounts linked to this user
21
NANAlinkRefWhat is an "account" in this context?NAAccounts linked to this user
22
Name/*name (multi-part)The components of the user's name. Service providers MAY return just the full name as a single string in the formattedsub-attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined.formerly known as
23
NAname.nameTypeNAName/typeNA
24
name (1 value, multi-part, required)
25
namename.formattedfullNameup to exporter/provisioner to format if desired - formatted The full name, including all middle names, titles, and suffixes as appropriate,
formatted for display (e.g., "Ms. Barbara Jane Jensen, III").
preferred name
26
lastnamefamilyNamefamilyNameName/family - familyName The family name of the User, or last name in most Western languages
(e.g., "Jensen" given the full name "Ms. Barbara Jane Jensen, III").
typed name (e.g. legal): both string and structured forms
27
firstnamegivenNamegivenNameName/given - givenName The given name of the User, or first name in most Western languages
(e.g., "Barbara" given the full name "Ms. Barbara Jane Jensen, III").
28
middlenamemiddleNameadditionalNameName/middle - middleName The middle name(s) of the User (e.g., "Jane" given the full name
"Ms. Barbara Jane Jensen, III").
29
prefixhonorificPrefixhonorificPrefixName/honorific - honorificPrefix The honorific prefix(es) of the User, or title in most Western languages
(e.g., "Ms." given the full name "Ms. Barbara Jane Jensen, III").
30
suffixhonorificSuffixhonoroficSuffixName/suffix - honorificSuffix The honorific suffix(es) of the User, or suffix in most Western languages
(e.g., "III" given the full name "Ms. Barbara Jane Jensen, III").
31
displaynamedisplayNameNAName/* (primary? type=preferred?)
(up to exporter/provisioner to format if desired)
displayName (1, optional)The name of the user, suitable for display to end-users. Each user returned MAY include a non-empty displayName value. The name SHOULD be the full name of the User being described, if known (e.g., "Babs Jensen" or "Ms. Barbara J Jensen, III") but MAY be a username or handle, if that is all that is available (e.g., "bjensen"). The value provided SHOULD be the primary textual label by which this User is normally displayed by the service provider when presenting it to end-users.
32
legalnameName/* (type=official?)NA
33
NANAnickNameName/* (type=profile?)nickName(1)
34
NANANAUrl/url (multivalued)profileUrl (1)Dead?A URI that is a uniform resource locator (as defined in Section 1.1.3 of [RFC3986]) and that points to a location representing the user's online profile (e.g., a web page). URIs are canonicalized per Section 6.2 of [RFC3986].
35
NANACoPersonRole/title (multivalued)title (1)
36
NAemployeeTypeCoPersonRole/affiliation (multivalued)userType (1)open vocab for affiliation
37
NApreferredLanguageNot currently supported, though individual attributes can be flagged with languagepreferredLanguage (1)needed for profile info
38
NAlocaleNot currently supportedlocale (1)
39
NAtimezoneAutodetected or CoPerson/timezonetimezone (1)
40
activationCoPerson[role]/status (non-boolean)active (1)A Boolean value indicating the user's administrative status. The definitive meaning of this attribute is determined by the service provider. As a typical example, a value of true implies that the user is able to log in, while a value of false implies that the user's account has been suspended.
41
NANAassignmentsWhat is an "account" in this context?Accounts linked to this user
42
NANAlinkRefWhat is an "account" in this context?NAAccounts linked to this user
43
statusNA
44
NAPassword/password (requires plugin to be enabled)password (1)needed in some provisioning processesThis attribute is intended to be used as a means to set, replace, or compare (i.e., filter for equality) a password. The cleartext value or the hashed value of a password SHALL NOT be returnable by a service provider. If a service provider holds the value locally, the value SHOULD be hashed. When a password is set or changed by the client, the cleartext password SHOULD be processed by the service provider as follows:
45
46
4.1.2. Multi-Valued User Attributes (see 2.4: there are standard sub-attributes: a 'type' a 'primary' which that can be present on at most one value)SCIM Reference on multivalued attributes: https://tools.ietf.org/html/rfc7643#section-2.4
SCIM list of attributes: https://tools.ietf.org/html/rfc7643#section-4.1.2
47
email --------
:type -
:address -
emailsemailAddressEmailAddress/*emails (with type sub-attribute)Email addresses for the User. The value SHOULD be specified according to [RFC5321]. Service providers SHOULD canonicalize the value according to [RFC5321], e.g., "bjensen@example.com" instead of "bjensen@EXAMPLE.COM". The "display" sub-attribute MAY be used to return the canonicalized representation of the email value. The "type" sub-attribute is used to provide a classification meaningful to the (human) user. The user interface should encourage the use of basic values of "work", "home", and "other"and MAY allow additional type values to be used at the discretion of SCIM clients.
48
telephone -----
:primary -
:type -
...
phoneNumberstelephoneNumberTelephoneNumber/*phoneNumbersE.164 Phone Number format: https://en.wikipedia.org/wiki/E.164. SCIM: Phone numbers for the user. The value SHOULD be specified
according to the format defined in [RFC3966], e.g.,
'tel:+1-201-555-0123'. Service providers SHOULD canonicalize the
value according to *[RFC3966] format, when appropriate. The
"display" sub-attribute MAY be used to return the canonicalized
representation of the phone number value. The sub-attribute
"type" often has typical values of "work", "home", "mobile",
"fax", "pager", and "other" and MAY allow more types to be defined
by the SCIM clients. *https://datatracker.ietf.org/doc/rfc3966/
49
Not explicitly supported, though could use Identifier of type 'im' or 'skype' etcimsInstant messaging address for the user. No official
canonicalization rules exist for all instant messaging addresses,
but service providers SHOULD, when appropriate, remove all
whitespace and convert the address to lowercase. The "type"
sub-attribute SHOULD take one of the following values: "aim",
"gtalk", "icq", "xmpp", "msn", "skype", "qq", "yahoo", or "other"
(representing currently popular IM services at the time of this
writing). Service providers MAY add further values if new IM
services are introduced and MAY specify more detailed
canonicalization rules for each possible value.
50
Not currently supportedphotos
51
NAAddress/*addresses (multi-part)
52
NAUp to provisioner to format address as desired - formatted The full mailing address, formatted for display or use with a mailing label.
This attribute MAY contain newlines.
53
NAAddress/street - streetAddress The full street address component, which may include house number, street name,
P.O. box, and multi-line extended street address information. This attribute MAY contain newlines.
54
NAAddress/locality - locality The city or locality component.
55
NAAddress/state - region The state or region component.
56
NAAddress/postal_code - postalCode The zip code or postal code component.
57
NAAddress/country - country The country name component. When specified, the value MUST be in ISO 3166-1 "alpha-2"
code format [ISO3166]; e.g., the United States and Sweden are "US" and "SE", respectively.
58
khCoGroupMember/*groups
59
khIndirectly supported via CoServiceentitlements
60
kh?employeeType?CoPersonRole/*roles
61
Certificate/* (metadata only)x509Certificates
62
SshKey/*
63
64
4.3. Enterprise User Schema Extension
65
employeeNumberIdentifier/identifier (type=employeenumber)employeeNumber (1)
66
costCenterNot currently supportedcostCenter (1)
67
organizationCoPersonRole/o, CoDepartmentorganization (1)
68
organizationalUnitCoDepartmentdivision (1)
69
organizationalUnitCoPersonRole/ou, CoDepartmentdepartment (1)
70
CoPersonRole/sponsormanager (1 value, multi-part)
71
As for identifiers, above - value The "id" of the SCIM resource representing the user's manager. RECOMMENDED.
72
- $ref The URI of the SCIM resource representing the User's manager. RECOMMENDED.
73
As for names, above - displayName The displayName of the user's manager. This attribute is OPTIONAL,
and mutability is "readOnly".
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100