ユーザー属性

ユーザー情報のプロビジョニングで必要とするユーザー属性を次のとおり定義する。

No 属性 例 SCIM属性名 サブ属性名 型 M V 必

須

1 ID 管理サーバー上の識

別子

e1234567 externalId String ○

2 サ ー ビ ス 利 用 時 の ユ ー ザー名

taro.nippon@com

.example.co.jp userName String ○

3 企業 OP でのログイン ID

e1234567 externalUser

Name (*2) String ○

4 IDトークンの識別子 ― idTokenClai

ms (*2) Complex ○ ○

5 Issuer識別子 https://op.com.ex

ample.co.jp issuer String ○

6 Subject識別子 e1234567 subject String ○

7 従業員番号 e1234567 employeeNu

mber (*1) String

8 名前（母国語）(*3) ― name Complex ○ 9 名前 日本 太郎 formatted String

10 名前（姓） 日本 familyName String 11 名前（名） 太郎 givenName String 12 表示用の名前（母国語）

(*3) 日本 太郎 displayName String

13 所 属 （ 主 務 ・ 母 国 語 ） (*3)

営業部営業1課 department

(*1) String

14 役 職 （ 主 務 ・ 母 国 語 ） (*3)

課長 title String

15 地域 ja-JP locale String

16 メールアドレス ― emails Complex ○ 17 メールアドレス taro.nippon@com

.example.co.jp value string

18 優先フラグ true primary Boolean 19 電話番号 ― phoneNumbe

rs Complex ○

20 値の種別 work type String 21 電話番号 03-1234-5678 value string 22 優先フラグ true primary Boolean

23 有効フラグ true active Boolean 24 多言語表現の名前 ― localNames

(*2) Complex ○

25 名前の言語 ja-JP locale String 26 名前 日本 太郎 formatted String 27 名前（姓） 日本 familyName String 28 名前（名） 太郎 givenName String 29 表示用の名前 日本 太郎 display String 30 優先フラグ true primary Boolean 31 値の種別 ja-JP type String 32 所属組織と役職 ― organization

alUnits (*2) Complex ○

33 所属の言語 ja-JP locale String 34 組織コード or 識別子 10010000 value String 35 組織名 営業1課 name String 36 表示用の組織名 営業部営業1課 display String 37 役職コード or 識別子 5000 titleValue String 38 役職名 課長 titleName String 39 表示用の役職名 課長 titleDisplay String 40 優先フラグ true primary Boolean 41 値の種別 ja-JP type String

 表中、MV欄に「○」が示された属性は、Multi-Valued属性である。

 (*1) SCIM Core SchemaでEnterpriseUserとして定義されているスキーマを使用する。

 (*2) EIWG 拡張スキーマとして定義して使用する。EIWG拡張スキーマの完全な定義は

付録B.1.2に掲載する。

 (*3) グローバル企業などではname, displayName, department, titleにローマ字表記を 設定し、母国語表記はlocalNames, organizationalUnitsの多言語表現で対応するという 用法もある。

String 型の属性は、少なくとも 255 バイトの文字列を扱えるように実装すべきである。文字

コードにはUTF-8を使用する。

SCIM Core Schemaでは、メールアドレスはemails属性に複数格納することができる。プロ

ビジョニングに使用するメールアドレスは、emails 属性が 1 つの値だけを持つ場合はその値を、

2 つ以上の値を持つ場合は primary 属性が trueに設定されたものを使用するように実装すべき

電話番号を表すphoneNumbers属性で用いる typeサブ属性（値の種別）の値として、SCIM Core Schemaでは "home", "work", "mobile", "fax", "pager", "other" の6つの値を標準的な値と して定義している。企業での利用を想定する場合、内線番号への対応が必要な場合がある。その 場合、内線番号を表す値として "extention" を指定するものとする。

SCIM で定義されている EnterpriseUser スキーマには、所属に関連する属性として division

とdepartmentの2つが用意されている。現状、多くのクラウドサービスでは所属の情報を1つ

の属性として必要としているため、当実装ガイドでは division 属性を未使用とし、department 属性のみを使用する。

当実装ガイドでは、ユーザーの名前を多言語で表現するための属性として localNames を、

ユーザーが所属する組織や役職を多言語で表現するための属性として organizatinalUnits を、

それぞれMulti-Valued属性として定義する。

これら2つの属性では、localeサブ属性に言語を表す値を設定することで、クラウドサービス が 必 要 と す る 言 語 の 値 を 取 り 出 す こ と に 対 応 す る 。locale サ ブ 属 性 に 設 定 す る 値 に は 、

[RFC5646] の形式で、IANA Language Subtag Registryに登録された値を用いる。同一言語で

異なる表記がある場合は、script subtag の値を含めることで対応する。具体的には、次のよう な値とする。

No 表記 localeサブ属性に使用する値

1 漢字表記 ja-JP 2 よみがな表記 ja-Hira-JP 3 ローマ字・英語表記 en-US

よみがな表記は「ひらがな」で値を設定するものとする。クラウドサービスが「カタカナ」で 値を必要とする場合は、クラウドサービス側で「ひらがな」で受け取った値を「カタカナ」に変 換する。

Multi-Valued 属性の場合に、type サブ属性を要求する実装系との互換性を保つため、type サ

ブ属性に明確な値の意味の定義がない場合はlocaleサブ属性と同一の値を設定する。

ユーザー作成、更新の処理を行なう場合は、ユーザーデータの属性としてこれら必要属性すべ てを含め、値を設定する必要がある。値を設定しなかった場合は、空値が指定されたものとして 作成、更新が行なわれる。表中で必須の表示がある属性については、必ず空値ではない値を設定 しなければならない。

クラウドサービスの特性として、これらの属性すべてを必要としない場合がある。ユーザーの 作成、更新処理において必要としない属性が指定されていた場合は、クラウドサービスはその値

を保管することなく破棄し、属性が指定されていなかったものとして処理を続行しなければなら ない。

クラウドサービスがこれらの属性すべてを必要としてない場合、クラウドサービスが、プロビ ジョニングに必要としているユーザー属性を利用企業に明示することで、利用企業の ID 管理 サーバーは、明示された必要ユーザー属性のみに限定してプロビジョニングを行なってもよい。

クラウドサービスとして、これら以外の属性を必要とする場合がある。その場合は、利用企業 との間で個別の取り決めを行ない、属性値を受け取るように実装する必要がある。その方法につ いては、当実装ガイドでは定義しない。

localNames属性のprimary属性がtrueである要素の各属性値と、name属性の属性値は一致

していることが望ましい。organizationalUnits属性のprimary属性がtrueである要素について、

nameサブ属性はdepartment属性と、titleNameサブ属性はtitle属性と一致していることが望 ましい。これらの整合性を保つ責務は、利用企業のID管理サーバーにある。

3.3.1.1. 組織情報、役職情報のプロビジョニングを実装する際の考慮点

当実装ガイドでは、組織と役職に関する情報を department 属性と title 属性に格納して扱う ようにしている。これは、最小限の実装として、ユーザーが所属する主務組織と主務役職の情報 をユーザーの属性としてプロビジョニングすることを可能にすることを意図したためである。

一方、クラウドサービスが企業の組織階層や役職の情報を扱う必要がある場合、組織情報や役 職情報のプロビジョニングが必要となる場合がある。

企業での利用を想定した場合、divisionとdepartmentの2階層ではなく、より深い階層構造 を持つ組織情報の表現や、兼務を含むユーザーの所属状態の表現、各所属でのユーザーの役職情 報の表現が必要となることがある。その場合は拡張スキーマを定義して専用の組織リソースや役 職リソース、そして拡張されたユーザーリソースの属性を使用することになる。

これらの実装方式の検討、ガイドライン化は今後の課題である。