プリザンターでGoogle WorkspaceのSAML SSOを設定してみる

Last updated at 2026-03-23Posted at 2026-02-22

はじめに

プリザンターは標準で SAML 2.0 によるシングルサインオン（SSO）に対応しています。Google Workspace を IdP（Identity Provider）として連携すれば、普段使っている Google アカウントでプリザンターにログインできるようになります。

この記事では、Google Workspace とプリザンターを SAML SSO で連携する手順を、以下の流れで紹介します。

プリザンター側の SAML 設定の全体像
Google Workspace 管理コンソールでのカスタム SAML アプリ作成
Google Workspace で取得した情報をプリザンターに設定する方法
既存の独自認証ユーザーを SSO に移行する方法

この記事はプリザンター 1.4 系以降を対象にしています。

プリザンター側の SAML 設定の全体像

SAML 認証の仕組み

SAML SSO では、プリザンターが SP（Service Provider）、Google Workspace が IdP（Identity Provider） として動作します。ログイン時の流れは以下のとおりです。

設定ファイルの場所

プリザンターの SAML 設定は、パラメータファイル Authentication.json で行います。

Implem.Pleasanter/App_Data/Parameters/Authentication.json

Authentication.json の主な設定項目

設定ファイルは大きく分けて以下の4つのブロックで構成されています。

ブロック	設定内容
ルート設定	`Provider` を `"SAML"` に設定して SAML 認証を有効化
`SPOptions`	プリザンター（SP）自身のエンティティ ID やコールバック URL
`IdentityProviders`	Google Workspace（IdP）のエンティティ ID、SSO URL、証明書情報
`Attributes`	SAML 属性とプリザンターのユーザー項目のマッピング

設定の流れ

作業は以下の順番で進めます。

Google Workspace 管理コンソール でカスタム SAML アプリを作成し、IdP 情報（エンティティ ID・SSO URL・証明書）を取得する
取得した IdP 情報を プリザンターの Authentication.json に設定する
プリザンターを 再起動 して設定を反映する
動作確認を行う

次のセクションから、それぞれの手順を詳しく見ていきましょう。

Google Workspace 管理コンソールでの設定

Google Workspace 側で「カスタム SAML アプリ」を作成し、プリザンターと連携するための IdP 情報を取得します。

1. カスタム SAML アプリの追加

Google 管理コンソールにログインします
左メニューから 「アプリ」 > 「ウェブアプリとモバイルアプリ」 を選択します
「アプリを追加」 > 「カスタム SAML アプリの追加」 をクリックします
アプリ名 に「Pleasanter」と入力し、「続行」 をクリックします

2. IdP 情報の取得

「Google IdP 情報」画面が表示されます。ここで以下の情報を控えておきます。

項目	説明	用途
SSO の URL	`https://accounts.google.com/o/saml2/idp?idpid=xxxxx`	`Authentication.json` の `SignOnUrl` に設定
エンティティ ID	`https://accounts.google.com/o/saml2?idpid=xxxxx`	`Authentication.json` の `EntityId`（IdP）に設定
証明書	X.509 証明書（PEM 形式）	プリザンターサーバーの証明書ストアにインポート

証明書は 「ダウンロード」 ボタンで .pem ファイルとしてダウンロードしておきましょう。後のプリザンター設定で必要になります。

「続行」 をクリックして次の画面に進みます。

3. サービスプロバイダ（SP）情報の入力

プリザンター側の情報を入力します。

項目	設定値	説明
ACS の URL	`https://<プリザンターのドメイン>/Users/SamlLogin`	SAML 認証後のコールバック URL
エンティティ ID	`https://<プリザンターのドメイン>/Saml2`	プリザンター（SP）のエンティティ ID
名前 ID の形式	`EMAIL`	メールアドレスを NameID として使用

<プリザンターのドメイン> は実際のプリザンターのURL に置き換えてください。例: pleasanter.example.com

「続行」 をクリックします。

4. 属性マッピングの設定

Google ディレクトリの属性をプリザンターの SAML 属性にマッピングします。「マッピングを追加」 で以下を設定してください。

基本の属性マッピング

Google のディレクトリ属性	アプリの属性	説明
Primary email	`MailAddress`	メールアドレス
First name	`FirstName`	名
Last name	`LastName`	姓

組織・部門のマッピング

プリザンターの部門（Depts）を SAML で自動管理するには、DeptCode（部門コード） と Dept（部門名） の両方を設定する必要があります。

Google Workspace の標準ディレクトリ属性には「部門名（Department）」はありますが「部門コード」はありません。そのため、カスタム属性 を作成して部門コードを管理します。

カスタム属性の作成手順

Google 管理コンソール > 「ディレクトリ」 > 「ユーザー」 を開きます
任意のユーザーを選択し、「ユーザー情報」 セクションの 「その��のユーザー情報の追加…」 をクリックします
あるいは 「ディレクトリ」 > 「ディレクトリ設定」 > 「カスタム属性」 から 「カスタム属性を追加」 をクリックします
以下のように設定します

項目	設定値
カテゴリ	`Pleasanter`（任意の名前）
カスタムフィールド名	`DeptCode`
情報の種類	テキスト
ユーザーや管理者に表示	はい
値の数	1 つの値

同様に UserCode（ユーザーコード）や TenantManager（管理者フラ��）も必要に応じて追加します。

カスタム属性の設定例

複数の属性を管理したい場合は、Pleasanter カテゴリにまとめて作成するのがおすすめです。

カスタムフィールド名	情報の種類	用途
`DeptCode`	テキスト	プリザンターの部門コード
`UserCode`	テキスト	プリザンターのユーザーコード
`TenantManager`	テキスト	テナント管理者フラグ（`true`/`false`）

各ユーザーのカスタム属性は、Google 管理コンソールのユーザー編集画面か、Google Directory API で一括設定できます。

属性マッピング（カスタム属性を含む完成版）

カスタム SAML アプリの属性マッピング画面で、以下をすべて設定します。

Google のディレクトリ属性	アプリの属性
Primary email	`MailAddress`
First name	`FirstName`
Last name	`LastName`
Department	`Dept`
Pleasanter - DeptCode	`DeptCode`
Pleasanter - UserCode	`UserCode`
Pleasanter - TenantManager	`TenantManager`

カスタム属性は 「カテゴリ名 - フィールド名」 の形式で表示されます。上の例ではカテゴリ名を Pleasanter とした場合の表記です。

プリザンターの Attributes 設定では、Name 属性にユーザー名を指定するか、FirstName + LastName の組み合わせで自動的にユーザー名を生成できます。ここでは FirstName / LastName を使う方法を紹介しています。

「完了」 をクリックしてアプリを保存します。

5. ユーザーアクセスの有効化

作成したアプリはデフォルトでオフになっています。利用するユーザーに対してアクセスを有効にしましょう。

作成した「Pleasanter」アプリの画面で 「ユーザーアクセス」 をクリックします
「オン（すべてのユーザー）」 を選択するか、特定の組織部門を選択します
「保存」 をクリックします

組織部門単位でアクセスを制御する場合は、「オン（一部の組織部門）」を選択して対象の組織部門を指定してください。

プリザンター側の設定

Google Workspace で取得した IdP 情報を使って、プリザンターの Authentication.json を設定します。

1. 証明書のインポート

Google Workspace からダウンロードした証明書（.pem ファイル）を、プリザンターのサーバーにインポートする必要があります。

Windows の場合

ダウンロードした .pem ファイルをダブルクリックし、 「証明書のインポートウィザード」 を開きます
保存場所 は Authentication.json の StoreLocation に合わせて選択します
- CurrentUser：現在のユーザー
- LocalMachine：ローカルコンピューター（IIS で動作する場合はこちら推奨）
証明書ストア は 「個人」（My）を選択します
インポート完了後、 「証明書の管理」（certlm.msc または certmgr.msc）を開き、インポートした証明書の 拇印（Thumbprint） をコピーします

Linux の場合

Linux ではディストリビューションによって証明書の管理方法が異なります。.NET の X509Store が証明書を検索できるよう、適切な場所にインポートする必要があります。

Debian / Ubuntu 系

# 1. 証明書を所定のディレクトリにコピー
sudo cp GoogleIDPCertificate.pem /usr/local/share/ca-certificates/google-idp.crt

# 2. 証明書ストアを更新
sudo update-ca-certificates

# 3. .NET が参照する個人ストアにもインポート
# プリザンターの実行ユーザーで実行してください
certutil -user -addstore My /usr/local/share/ca-certificates/google-idp.crt

Debian / Ubuntu 系では /usr/local/share/ca-certificates/ に .crt 拡張子で配置し、update-ca-certificates を実行するのが標準的な方法です。

RHEL / CentOS / AlmaLinux / Rocky Linux 系

# 1. 証明書を所定のディレクトリにコピー
sudo cp GoogleIDPCertificate.pem /etc/pki/ca-trust/source/anchors/google-idp.pem

# 2. 証明書ストアを更新
sudo update-ca-trust

# 3. .NET が参照する個人ストアにもインポート
# プリザンターの実行ユーザーで実行してください
certutil -user -addstore My /etc/pki/ca-trust/source/anchors/google-idp.pem

RHEL 系では /etc/pki/ca-trust/source/anchors/ に配置し、update-ca-trust を実行します。

Azure App Service の場合

Azure App Service でプリザンターをホストしている場合は、Azure ポータルから証明書をアップロードし、アプリ設定で読み込みを有効にします。

Azure ポータルで対象の App Service を開きます
「証明書」 メニューを開き、 「公開キー証明書 (.cer) の追加」 をクリックします
名前に任意の識別名（例: google-idp）を入力し、Google Workspace からダウンロードした .pem ファイルをアップロードします
アップロード完了後、一覧に表示された 拇印（Thumbprint） をコピーします
「構成」→「アプリケーション設定」 で WEBSITE_LOAD_CERTIFICATES にコピーした拇印（またはすべての証明書を読み込む場合は *）を設定します
設定を保存し、App Service を再起動します

WEBSITE_LOAD_CERTIFICATES を設定しないと、アップロードした証明書がアプリのプロセスから参照できません。必ず設定してください。

App Service での StoreLocation の設定

App Service（Windows）では、読み込まれた証明書は CurrentUser の My（個人）ストアに配置されます。Authentication.json の StoreLocation は CurrentUser を指定してください。

Authentication.json（Azure App Service の場合）

"IdentityProviders": [
    {
        "EntityId": "https://accounts.google.com/o/saml2?idpid=XXXXXXXXXX",
        "SignOnUrl": "https://accounts.google.com/o/saml2/idp?idpid=XXXXXXXXXX",
        "FindValue": "A1B2C3D4E5F6...",
        "StoreLocation": "CurrentUser",
        "StoreName": "My"
    }
]

App Service（Linux）の場合、公開キー証明書は /var/ssl/certs/<拇印>.der にファイルとして配置されます。ただし .NET の X509Store からアクセスするには WEBSITE_LOAD_CERTIFICATES の設定が必要な点は同じです。

拇印（Thumbprint）の確認（Linux）

どのディストリビューションでも、拇印の確認方法は共通です。

# SHA-1 拇印を確認
openssl x509 -in GoogleIDPCertificate.pem -fingerprint -sha1 -noout

# 出力例: SHA1 Fingerprint=A1:B2:C3:D4:E5:F6:...
# コロンを除去した文字列（A1B2C3D4E5F6...）を Authentication.json の FindValue に設定

拇印をそのままコピーできる形式で取得するには以下が便利です。

openssl x509 -in GoogleIDPCertificate.pem -fingerprint -sha1 -noout | sed 's/SHA1 Fingerprint=//;s/://g'

ディストリビューション別の対応表

項目	Debian / Ubuntu	RHEL / CentOS / AlmaLinux
証明書の配置先	`/usr/local/share/ca-certificates/`	`/etc/pki/ca-trust/source/anchors/`
拡張子	`.crt`	`.pem`
更新コマンド	`update-ca-certificates`	`update-ca-trust`
必要パッケージ	`ca-certificates`（通常プリインストール）	`ca-certificates`（通常プリインストール）

.NET の X509Store でアクセスする場合、証明書を CA トラストストアに追加するだけでは不十分なケースがあります。certutil -user -addstore My でユーザーの個人ストアにもインポートしておくのが確実です。certutil は libnss3-tools（Debian / Ubuntu）または nss-tools（RHEL 系）パッケージに含まれています。

2. Authentication.json の編集

Authentication.json を以下のように編集します。変更が必要な箇所にコメントを入れています。

Implem.Pleasanter/App_Data/Parameters/Authentication.json

{
    "Provider": "SAML",
    "SamlParameters": {
        "Attributes": {
            "FirstName": "FirstName",
            "LastName": "LastName",
            "DeptCode": "DeptCode",
            "Dept": "Dept",
            "UserCode": "UserCode",
            "TenantManager": "TenantManager",
            "MailAddress": "{NameId}"
        },
        "SamlTenantId": 1,
        "DisableOverwriteName": false,
        "SPOptions": {
            "EntityId": "https://pleasanter.example.com/Saml2",
            "ReturnUrl": "https://pleasanter.example.com/Users/SamlLogin",
            "AuthenticateRequestSigningBehavior": "IfIdpWantAuthnRequestsSigned",
            "OutboundSigningAlgorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
            "MinIncomingSigningAlgorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
        },
        "IdentityProviders": [
            {
                "EntityId": "https://accounts.google.com/o/saml2?idpid=xxxxx",
                "SignOnUrl": "https://accounts.google.com/o/saml2/idp?idpid=xxxxx",
                "LogoutUrl": null,
                "AllowUnsolicitedAuthnResponse": true,
                "Binding": "HttpPost",
                "WantAuthnRequestsSigned": false,
                "DisableOutboundLogoutRequests": true,
                "LoadMetadata": false,
                "SigningCertificate": {
                    "StoreName": "My",
                    "StoreLocation": "LocalMachine",
                    "X509FindType": "FindByThumbprint",
                    "FindValue": "A1B2C3D4E5F6..."
                }
            }
        ]
    }
}

3. 設定項目の解説

Provider

設定値	説明
`null`	独自認証（デフォルト）
`"SAML"`	SAML 認証を有効化（シングルテナント）
`"SAML-MultiTenant"`	SAML 認証を有効化（マルチテナント）

Attributes（属性マッピング）

Google Workspace の属性マッピングで設定した「アプリの属性」名と、プリザンター側の属性名を対応付けます。

プリザンター属性	説明	Google 側の設定
`FirstName`	名	First name
`LastName`	姓	Last name
`DeptCode`	部門コード	Pleasanter - DeptCode（カスタム属性）
`Dept`	部門名	Department
`UserCode`	ユーザーコード	Pleasanter - UserCode（カスタム属性）
`TenantManager`	テナント管理者	Pleasanter - TenantManager（カスタム属性）
`MailAddress`	メールアドレス	`{NameId}` で NameID を自動使用

{NameId} は SAML レスポンスの NameID（ここではメールアドレス）を自動的に使用する特別な記法です。Google Workspace で名前 ID の形式を EMAIL に設定していれば、ユーザーのメールアドレスが入ります。

部門（Depts）の自動管理

SAML ログイン時に DeptCode と Dept の両方が設定されていると、プリザンターは以下の処理を自動的に行います。

DeptCode に一致する部門が存在しなければ 新規作成
存在すれば部門名を Dept の値で 上書き更新
ユーザーをその部門に 自動的に所属 させる

DeptCode を空文字列で送信すると、ユーザーの部門所属が解除されます（DeptId = 0）。Google Workspace 側でカスタム属性を空にした場合にこの動作になるため注意してください。

Dept（部門名）だけを設定して DeptCode を省略した場合、部門の自動管理は行われません。DeptCode と Dept は必ずセットで設定してください。

グループの管理について

プリザンターの SAML 認証では、グループ（Groups）の自動管理には対応していません。LDAP 連携ではグループ同期がサポートされていますが、SAML ではユーザーと部門の管理のみが可能です。

グループの管理が必要な場合は、以下のいずれかの方法で対応してください。

方法	説明
プリザンター管理画面	管理画面からグループを手動で作成・メンバーを管理する
プリザンター API	グループ管理用の API を使ってスクリプトで一括管理する
部門で代替	権限管理の単位を部門にまとめ、SAML の `DeptCode` で自動管理する

部門はSAMLログインのたびに自動更新されるため、Google Workspace 側で組織変更があっても次回ログイン時にプリザンター側に反映されます。権限管理の単位として活用すると、ユーザーの所属管理を一元化できます。

SAML のユーザー同期タイミングと BackgroundService

プリザンターの LDAP 連携では BackgroundService.json の SyncByLdap を有効にすることで、指定時刻にバックグラウンドで全ユーザーを一括同期できます。一方、SAML にはバックグラウンド同期機能がありません。

認証方式	同期タイミング	同期対象	設定
LDAP	定期実行（BackgroundService）	ディレクトリ内の全ユーザー	`BackgroundService.json` の `SyncByLdap: true`
SAML	ログイン時のみ	ログインした個別ユーザー	なし（自動）

つまり SAML の場合、Google Workspace 側でユーザーの部門や名前を変更しても、そのユーザーが次回プリザンターにログインするまでプリザンター側には反映されません。

退職者のアカウント無効化など、セキュリティ上すぐに反映したい変更は SAML 同期では即時反映できません。Google Workspace 側でユーザーを無効化すれば SAML ログイン自体ができなくなりますが、プリザンター側のユーザーは有効なまま残ります。プリザンター側でもユーザーを無効化する運用が必要です。

LDAP 連携を併用できる環境であれば、認証は SAML で行い、ユーザー同期は LDAP の SyncByLdap で定期実行するという構成も検討できます。ただし Google Workspace の場合は LDAP サービス（Secure LDAP）の有効化が別途必要になります。

Google Workspace Secure LDAP の併用

SAML 単体ではバックグラウ��ド同期ができないため、Google Workspace の Secure LDAP（LDAPS）サービスを併用する構成も選択肢になります。認証は SAML、ユーザー同期は LDAP という役割分担です。

構成イメージ

メリット

メリット	説明
ユーザー情報の定期一括同期	`SyncByLdap` で全ユーザーの属性を定期的に最新化できる
退職者の即時反映	Google Workspace で無効化したユーザーを LDAP 同期で自動的に無効化できる
ログイン不要の同期	ユーザーがログインしなくても属性変更が反映される
SAML の認証機能はそのまま	SSO・多要素認証などは SAML 側で引き続き利用可能

デメリット

デメリット	説明
Secure LDAP の追加設定が必要	Google Workspace 管理コンソールで Secure LDAP サービスを有効化し、クライアント証明書を発行する必要がある
対応エディションの制限	Secure LDAP は Business Plus / Enterprise / Education Fundamentals 以上のエディションでのみ利用可能
設定の複雑化	`Authentication.json` と `BackgroundService.json` の両方を設定・管理する必要がある
属性マッピングの二重管理	SAML と LDAP で属性マッピングをそれぞれ設定するため、不整合に注意が必要
ネットワーク要件	プリザンターサーバーから Google の LDAPS エンドポイント（`ldap.google.com:636`）への通信が必要

併用時の設定概要

Implem.Pleasanter/App_Data/Parameters/BackgroundService.json

{
    "SyncByLdap": true,
    "SyncByLdapTime": [ "02:00", "14:00" ]
}

Implem.Pleasanter/App_Data/Parameters/Authentication.json

{
    "Provider": "SAML",
    "LdapParameters": [
        {
            "LdapSearchRoot": "LDAP://ldap.google.com:636/dc=example,dc=com",
            "LdapSearchProperty": "mail",
            "LdapTenantId": 1,
            "LdapMailAddress": "mail",
            "LdapFirstName": "givenName",
            "LdapLastName": "sn"
        }
    ],
    "SamlParameters": {
        ...
    }
}

SAML と LDAP を併用する場合、Provider は "SAML" のまま設定します。LdapParameters は SyncByLdap によるバックグラウンド同期専用で、認証方式には影響しません。

Secure LDAP を使わずに SAML 単体で運用する場合は、退職者の無効化をプリザンターの管理画面や API で手動・スクリプト対応する運用フローを整えておくのがおすすめです。

SAML で設定可能な属性の一覧

Authentication.json の Attributes に指定できる全属性の一覧です。

属性キー	マッピング先	値の型	説明
`MailAddress`	MailAddresses テーブル	文字列	メールアドレス。`{NameId}` で NameID を使用可
`Name`	Users.Name	文字列	表示名（フルネーム）。`FirstName`/`LastName` より優先される
`FirstName`	Users.FirstName	文字列	名。`Name` が未設定の場合に使用
`LastName`	Users.LastName	文字列	姓。`Name` が未設定の場合に使用
`FirstAndLastNameOrder`	Users.FirstAndLastNameOrder	数値	姓名の結合順。`1` = 名→姓、`2` = 姓→名
`UserCode`	Users.UserCode	文字列	ユーザーコード
`Birthday`	Users.Birthday	日付	誕生日（パース可能な日付文字列）
`Gender`	Users.Gender	文字列	性別
`Language`	Users.Language	文字列	言語コード（`ja`、`en` など）
`TimeZone`	Users.TimeZone	文字列	タイムゾーン（`Asia/Tokyo` など）
`TenantManager`	Users.TenantManager	真偽値	テナント管理者フラグ。`true`/`false`（大文字小文字不問）
`DeptCode`	Depts.DeptCode	文字列	部門コード。`Dept` とセットで指定が必要
`Dept`	Depts.DeptName	文字列	部門名。`DeptCode` とセットで指定が必要
`Body`	Users.Body	文字列	備考（自由テキスト）

MailAddress の指定方法

MailAddress は3つの指定方法があります。

指定方法	例	動作
`{NameId}`	`"MailAddress": "{NameId}"`	SAML の NameID をメールアドレスとして使用
クレーム名	`"MailAddress": "mail"`	指定クレームの値をメールアドレスとして使用
フォールバック	`"MailAddress": "mail\|{NameId}"`	指定クレームを探し、なければ NameID を使用

Name と FirstName / LastName の優先順位

表示名は以下の優先順位で決定されます。

優先度	条件	表示名
1	`Name` が設定されている	`Name` の値をそのまま使用
2	`FirstName` と `LastName` の両方	`FirstAndLastNameOrder` に従って結合
3	`LastName` のみ	`LastName` の値
4	`FirstName` のみ	`FirstName` の値

FirstAndLastNameOrder を指定しない場合のデフォルトは 姓→名（山田太郎）です。日本語名なら通常は指定不要です。

DisableOverwriteName を true に設定すると、既存ユーザーの名前は SAML ログイン時に上書きされなくなります。新規ユーザー作成時のみ反映されます。

IdP が属性を送信しなかった場合の動作

Authentication.json の Attributes に属性を定義していても、IdP（Google Workspace）が対応するクレームを送信しなかった場合、その属性の更新はスキップされます。既存ユーザーなら現在の値がそのまま保持され、新規ユーザーならデータベースのデフォルト値が使われます。

属性の状態	既存ユーザー	新規ユーザー
IdP から値が送信された	IdP の値で上書き	IdP の値で設定
IdP から値が送信されなかった	現在の値を保持	DB のデフォルト値
`Attributes` に定義していない	変更なし	DB のデフォルト値

属性に既定値を持たせる方法

プリザンターの SAML 属性マッピングには、固定値やデフォルト値を直接設定する機能はありません。Attributes の値は IdP のクレーム名として解釈されるため、"Language": "ja" と書いても「ja というクレーム名」を探す動作になり、意図した結果にはなりません。

既定値を持たせたい場合は、Google Workspace 側のカスタム属性で値を設定する 方法が確実です。

方法 1：全ユーザーに固定値を設定する

Google 管理コンソールのカスタム属性に値を一括設定します。

Google Workspace のカスタム属性に Language、TimeZone などを作成する
全ユーザーに対して固定値を設定する（例: Language = ja、TimeZone = Asia/Tokyo）
カスタム SAML アプリの属性マッピングに追加する

ユーザー数が多い場合は、Google Admin SDK の Directory API で一括更新すると効率的です。

# Google Admin SDK（gcloud CLI）でカスタム属性を一括設定する例
# ユーザーのカスタムスキーマを更新
gcloud identity users update user@example.com \
  --custom-schemas='Pleasanter={Language:ja,TimeZone:Asia/Tokyo}'

方法 2：`Attributes` から除外して DB のデフォルト値を使う

IdP から送信する必要がない属性は、Attributes から定義自体を削除します。定義がなければ SAML ログイン時に一切更新されず、プリザンター側で設定した値がそのまま使われます。

Authentication.json（Language・TimeZoneをSAML同期対象から除外する例）

"Attributes": {
    "FirstName": "FirstName",
    "LastName": "LastName",
    "DeptCode": "DeptCode",
    "Dept": "Dept",
    "MailAddress": "{NameId}"
}

この構成では Language や TimeZone は Attributes に含まれていないため、SAML ログイン時に更新されません。新規ユーザーは DB のデフォルト値で作成され、その後プリザンターの管理画面で個別に変更できます。

方法の使い分け

方法	適しているケース
方法 1（IdP 側で全ユーザーに設定）	全ユーザーに同じ値を強制したい場合。IdP が正とする運用
方法 2（Attributes から除外）	プリザンター側で個別管理したい場合。ユーザーごとに異なる値を設定

方法 1 と方法 2 を属性ごとに組み合わせることもできます。例えば Language は IdP から送信して統一し、TimeZone は Attributes から除外してプリザンター側で個別管理するといった運用が可能です。

プリザンター側の設定で既定値を管理できるか？

プリザンターには Service.json に DefaultLanguage や TimeZoneDefault の設定項目がありますが、SAML によるユーザー新規作成時にはこれらの値は参照されません。

設定箇所	SAML 新規作成時の適用	備考
`Service.json`（`DefaultLanguage`・`TimeZoneDefault`）		画面からのユーザー作成時のみ有効
テナント設定（言語・タイムゾーン）		画面操作で使用される設定

これは、SAML ユーザー作成処理がプリザンターの通常のユーザー作成パス（Controller → Model）を経由せず、Saml.cs 内で直接 SQL を発行する設計になっているためです。

Service.json の DefaultLanguage を ja に設定していても、SAML で新規作成されたユーザーの言語は ja にはなりません。SAML ユーザーに言語やタイムゾーンを確実に設定するには、方法 1（IdP 側でカスタム属性として送信） を使用してください。

どうしてもプリザンター側で一括管理したい場合は、SAML ユーザー作成後に SQL で更新する方法があります。

-- SAML で作成されたユーザーの言語・タイムゾーンを一括設定
UPDATE "Users"
SET
    "Language" = 'ja',
    "TimeZone" = 'Asia/Tokyo'
WHERE "TenantId" = 1
    AND "Language" = ''
    AND "TenantManager" = false;

ただしこの SQL は手動実行が必要で、SAML ログインのたびに自動適用されるものではありません。新規ユーザーが追加されるたびに実行するか、定期ジョブとして仕組み化する必要があります。

SPOptions

項目	設定値	説明
`EntityId`	`https://<ドメイン>/Saml2`	Google Workspace の SP 情報で入力したエンティティ ID と一致させる
`ReturnUrl`	`https://<ドメイン>/Users/SamlLogin`	Google Workspace の SP 情報で入力した ACS の URL と一致させる

IdentityProviders

項目	設定値	説明
`EntityId`	Google の「エンティティ ID」	Google 管理コンソールで表示された値
`SignOnUrl`	Google の「SSO の URL」	Google 管理コンソールで表示された値
`FindValue`	証明書の拇印	インポートした証明書の Thumbprint
`StoreLocation`	`CurrentUser` or `LocalMachine`	証明書をインポートした場所

4. 設定の反映

設定ファイルを保存したら、プリザンターに設定を反映します。方法は 2 つあります。

方法 A：パラメータリロード URL にアクセスする（推奨）

プリザンターにはアプリを再起動せずにパラメータを再読み込みする URL が用意されています。特権ユーザー（PrivilegedUsers）でログインした状態で、以下の URL にアクセスするだけでパラメータが反映されます。

https://<プリザンターのドメイン>/admins/reloadparameters

この URL を使用するには、事前に Security.json の PrivilegedUsers に対象ユーザーの LoginId を登録しておく必要があります。

Implem.Pleasanter/App_Data/Parameters/Security.json（抜粋）

{
    "PrivilegedUsers": ["Administrator"]
}

PrivilegedUsers の設定変更自体はアプリの再起動が必要です。初回のみ方法 B で反映してください。

方法 B：アプリを再起動する

# Linux（systemd）の場合
sudo systemctl restart pleasanter

# IIS の場合はアプリケーションプールをリサイクル

パラメータリロード URL が使えない環境（特権ユーザー未設定、ネットワーク制約など）ではこちらの方法を使います。

5. 動作確認

プリザンターのログイン画面にアクセスします
SAML が有効になっていると、通常のログインフォーム（ID / パスワード）に加えて 「SSO ログイン」ボタン が表示されます
「SSO ログイン」 ボタンをクリックすると、Google のログイン画面にリダイレクトされます
Google アカウントでログインすると、プリザンターのトップページに遷移します

SAML を有効にしても IdP への自動リダイレクトは行われません。ログイン画面には ID / パスワード欄がそのまま残り、ローカル認証も引き続き使用できます。SSO を利用する場合は「SSO ログイン」ボタンからログインします。

初回ログイン時はプリザンターにユーザーが自動作成されます。Attributes のマッピングに従って、名前・メールアドレス・部署が設定されます。

SAML ユーザーとローカルユーザーの混在運用

プリザンターでは Provider を "SAML" に設定した場合でも、SAML ユーザーとローカル認証ユーザーを混在して運用できます。

ログインフローの違い

ログイン方法	操作	認証先
SSO ログイン	ログイン画面の「SSO ログイン」ボタンをクリック	Google Workspace（IdP）
ローカルログイン	ID / パスワード欄に入力して「ログイン」ボタンをクリック	プリザンター DB（パスワードハッシュ照合）

どちらの方法でログインしても、プリザンター��での操作・権限は同じです。

ローカルログインの制限（AllowOriginalLogin）

SAML への移行が完了し、ローカルログインを制限したい場合は、テナントの契約設定で AllowOriginalLogin を 0 に設定できます。この設定を行うと テナント管理者以外のユーザーはローカルログインができなくなります。

テナント管理者（TenantManager = true）はローカルログインの制限対象外です。これは、IdP 障害時にも管理者がログインできるようにするための設計です。万が一 Google Workspace 側に障害が発生した場合でも、テナント管理者は ID / パスワードでログインして運用を継続できます。

混在運用の活用例

シナリオ	運用方法
段階的な SSO 移行	まず一部のユーザーで SSO を検証し、問題なければ全ユーザーに展開
外部パートナーとの併用	社内ユーザーは SSO、外部パートナーはローカル認証
IdP 障害時の緊急対応	管理者がローカルログインで設定変更や復旧作業を実施

ログイン画面のカスタマイズ

SAML SSO を有効にしたログイン画面の改善方法を紹介します。このカスタマイズは Google Workspace に限らず、どの IdP を使った SSO でも共通 で利用できます。

通常の SSO を有効にしたログイン画面は次の画像のようになります。

ただしこれだと SSO への視線誘導が弱いため、通常の ID / パスワード欄を折りたたんで SSO ボタンを目立たせると、ユーザーの迷いを減らせます。拡張スタイルと拡張スクリプトで実現できます。

拡張スタイル

以下の CSS を App_Data/Parameters/ExtendedStyles/ に配置します。

App_Data/Parameters/ExtendedStyles/login-collapse.css

/* ログインページのみに適用（body#login で限定） */

/* SSO ログインボタンをフォーム上部に移動して強調 */
body#login #SsoLogin {
  order: -1;
  margin-bottom: 24px;
  padding: 16px;
  background-color: #f0f7ff;
  border: 1px solid #4285f4;
  border-radius: 8px;
}

body#login #SsoLogin .ssoLoginMessage {
  font-size: 1.1em;
  font-weight: bold;
  color: #1a73e8;
}

/* ログインエリアを flexbox で順序制御 */
body#login #Logins {
  display: flex;
  flex-direction: column;
}

/* ID/パスワード欄・ログインボタンを初期状態で折りたたみ */
body#login #login-fields-body,
body#login #LoginCommands {
  max-height: 0;
  overflow: hidden;
  opacity: 0;
  transition: max-height 0.3s ease, opacity 0.3s ease, margin 0.3s ease;
  margin: 0;
}

/* 展開時のスタイル */
body#login #login-fields-body.expanded,
body#login #LoginCommands.expanded {
  max-height: 300px;
  opacity: 1;
  margin-top: 8px;
}

/* 折りたたみトグルボタン */
body#login #LocalLoginToggle {
  cursor: pointer;
  color: #666;
  font-size: 0.9em;
  text-align: center;
  padding: 8px;
  margin-top: 16px;
  border: 1px solid #ddd;
  border-radius: 4px;
  background: #fafafa;
  order: 1;
}

body#login #LocalLoginToggle:hover {
  background: #f0f0f0;
  color: #333;
}

body#login #LocalLoginToggle::before {
  content: "▶ ";
}

body#login #LocalLoginToggle.expanded::before {
  content: "▼ ";
}

拡張スクリプト

以下の JavaScript を App_Data/Parameters/ExtendedScripts/ に配置します。

App_Data/Parameters/ExtendedScripts/login-collapse.js

// ログインページのみで実行
if (document.body.id === 'login') {
  $(function () {
    var $logins = $('#Logins');
    var $fields = $('#login-fields-body');
    var $commands = $('#LoginCommands');

    // 折りたたみトグルボタンを挿入
    var $toggle = $('<div>', {
      id: 'LocalLoginToggle',
      text: 'ID / パスワードでログイン'
    });

    // SSO ボタンの後に配置
    var $sso = $('#SsoLogin');
    if ($sso.length) {
      $sso.after($toggle);
    } else {
      // SSO ボタンがない場合はフォームを折りたたまない
      return;
    }

    // トグルボタンのクリックイベント
    $toggle.on('click', function () {
      var isExpanded = $fields.hasClass('expanded');
      $fields.toggleClass('expanded');
      $commands.toggleClass('expanded');
      $toggle.toggleClass('expanded');
      $toggle.text(isExpanded
        ? 'ID / パスワードでログイン'
        : 'ID / パスワードでログイン');

      // 展開時に LoginId にフォーカス
      if (!isExpanded) {
        setTimeout(function () {
          $('#Users_LoginId').focus();
        }, 300);
      }
    });
  });
}

配置後の確認

上記ファイルを配置してパラメータリロード URL（/admins/reloadparameters）にアクセスするか、プリザンターを再起動します
ログイン画面にアクセスし、SSO ボタンが上部に表示され、ID / パスワード欄が折りたたまれていることを確認します
「ID / パスワードでログイン」をクリックすると、入力欄が展開されることを確認します

拡張スタイル・拡張スクリプトはファイルベースの場合、全ページに読み込まれます。ログインページ以外では body#login セレクタと document.body.id === 'login' の条件により処理がスキップされるため、他のページへの影響はありません。

既存ユーザーの SSO 移行方法

すでにプリザンターを独自認証（ローカル認証）で運用している場合、SAML SSO に切り替える際に既存ユーザーのデータを引き継ぐ方法を解説します。

SAML ログイン時のユーザー照合の仕組み

プリザンターの SAML 認証では、IdP から返される NameID の値を LoginId としてユーザーを照合します。

つまり、Google アカウントのメールアドレス（NameID）とプリザンターの LoginId が一致していれば、既存ユーザーがそのまま引き継がれます。

移行パターン

パターン A：LoginId がメールアドレスと同じ場合

既存ユーザーの LoginId が Google Workspace のメールアドレスと同じであれば、特別な作業は不要です。SAML を有効にするだけで既存ユーザーがそのまま使われます。

既存の LoginId	Google メールアドレス	結果
`taro@example.com`	`taro@example.com`	✅ 既存ユーザーを継続利用

パターン B：LoginId がメールアドレスと異なる場合

LoginId が taro のように短い ID の場合は、SAML 切り替え前に LoginId をメールアドレスに変更しておく必要があります。

既存の LoginId	Google メールアドレス	そのままだと
`taro`	`taro@example.com`	❌ 新規ユーザーが作成される

対応手順：

プリザンターの管理画面で対象ユーザーの 「ログインID」 をメールアドレスに変更します
全ユーザーの変更が完了してから、Authentication.json の Provider を "SAML" に変更します

LoginId を変更するとユーザーは変更後の LoginId でしかログインできなくなります。SAML 切り替え直前に一括で変更するのがおすすめです。

一括変更の方法

ユーザー数が多い場合は、SQL で一括更新すると効率的です。

-- LoginId をメールアドレスに一括更新する例
-- MailAddresses テーブルからメールアドレスを取得して LoginId に設定
UPDATE "Users"
SET "LoginId" = ma."MailAddress"
FROM (
    SELECT "OwnerId", "MailAddress"
    FROM "MailAddresses"
    WHERE "OwnerType" = 'Users'
) ma
WHERE "Users"."UserId" = ma."OwnerId"
  AND "Users"."LoginId" <> ma."MailAddress"
  AND "Users"."TenantId" = 1;

SQL を直接実行する場合は、必ず事前にバックアップを取ってから行ってください。

移行のおすすめ手順

安全に移行するために、以下の手順をおすすめします。

事前準備
- 全ユーザーの LoginId と Google メールアドレスの対応一覧を作成する
- データベースのバックアップを取る
LoginId の変更（パターン B の場合）
- ユーザーの LoginId を Google メールアドレスに変更する
- 変更後、独自認証でログインできることを確認する
SAML 設定の有効化
- Authentication.json を編集して SAML を有効化する
- プリザンターを再起動する
動作確認
- テストユーザーで SAML ログインを確認する
- 既存データ（レコード・権限設定など）が引き継がれていることを確認する
全ユーザーへの展開
- 問題がなければ全ユーザーに SAML ログインを案内する

RejectUnregisteredUser の活用

Authentication.json の RejectUnregisteredUser を true に設定すると、プリザンターに登録されていないユーザーの SAML ログインを拒否できます。

Implem.Pleasanter/App_Data/Parameters/Authentication.json

{
    "Provider": "SAML",
    "RejectUnregisteredUser": true,
    "SamlParameters": {
        ...
    }
}

設定値	動作
`false`（デフォルト）	未登録ユーザーは SAML ログイン時に自動作成される
`true`	事前にプリザンターに登録済みのユーザーのみ SAML ログイン可能

組織の方針として「管理者が事前に登録したユーザーのみ利用可」としたい場合に便利です。

トラブルシューティング

SAML SSO の設定でよくある問題と対処法をまとめます。

症状	考えられる原因	対処法
ログイン画面が表示されず 500 エラー	`Authentication.json` の JSON 構文エラー	JSON の書式を確認する（カンマ漏れ、括弧の不一致など）
Google ログイン後にエラー画面	ACS URL またはエンティティ ID の不一致	Google 管理コンソールとプリザンターの `SPOptions` で同じ値になっているか確認する
「証明書が見つからない」エラー	証明書のインポート先が異なる	`StoreLocation`（`CurrentUser`/`LocalMachine`）と `StoreName`（`My`）がインポート先と一致しているか確認する
「拇印が一致しない」エラー	拇印のコピーミス	スペースやコロンを除去した文字列になっているか確認する
SAML ログインできるが新規ユーザーになる	NameID と既存 LoginId の不一致	既存ユーザーの LoginId を Google メールアドレスに変更する
未登録ユーザーがログインできない	`RejectUnregisteredUser` が `true`	事前にプリザンターにユーザーを登録するか、`false` に変更する

まとめ

Google Workspace とプリザンターを SAML SSO で連携する手順を紹介しました。

Google Workspace 管理コンソール でカスタム SAML アプリを作成し、IdP 情報（エンティティ ID・SSO URL・証明書）を取得する
プリザンターの Authentication.json で Provider を "SAML" に設定し、IdP 情報と属性マッピングを記述する
既存の独自認証ユーザーから移行する場合は、LoginId を Google メールアドレスに一致させる ことで既存データを引き継げる
RejectUnregisteredUser を活用すれば、ユーザーの自動作成を抑止して管理者が許可したユーザーのみ利用可にできる

SSO を導入すると、パスワード管理の手間が減り、Google Workspace の多要素認証といったセキュリティ機能も活用できます。ぜひ試してみてください。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

プリザンターでGoogle WorkspaceのSAML SSOを設定してみる

はじめに

プリザンター側の SAML 設定の全体像

SAML 認証の仕組み

設定ファイルの場所

Authentication.json の主な設定項目

設定の流れ

Google Workspace 管理コンソールでの設定

1. カスタム SAML アプリの追加

2. IdP 情報の取得

3. サービスプロバイダ（SP）情報の入力

4. 属性マッピングの設定

基本の属性マッピング

組織・部門のマッピング

カスタム属性の作成手順

カスタム属性の設定例

属性マッピング（カスタム属性を含む完成版）

5. ユーザーアクセスの有効化

プリザンター側の設定

1. 証明書のインポート

Windows の場合

Linux の場合

Debian / Ubuntu 系

RHEL / CentOS / AlmaLinux / Rocky Linux 系

Azure App Service の場合

App Service での StoreLocation の設定

拇印（Thumbprint）の確認（Linux）

ディストリビューション別の対応表

2. Authentication.json の編集

3. 設定項目の解説

Provider

Attributes（属性マッピング）

部門（Depts）の自動管理

グループの管理について

SAML のユーザー同期タイミングと BackgroundService

Google Workspace Secure LDAP の併用

構成イメージ

メリット

デメリット

併用時の設定概要

SAML で設定可能な属性の一覧

MailAddress の指定方法

Name と FirstName / LastName の優先順位

IdP が属性を送信しなかった場合の動作

属性に既定値を持たせる方法

方法 1：全ユーザーに固定値を設定する

方法 2：Attributes から除外して DB のデフォルト値を使う

方法の使い分け

プリザンター側の設定で既定値を管理できるか？

SPOptions

IdentityProviders

4. 設定の反映

方法 A：パラメータリロード URL にアクセスする（推奨）

方法 B：アプリを再起動する

5. 動作確認

SAML ユーザーとローカルユーザーの混在運用

ログインフローの違い

ローカルログインの制限（AllowOriginalLogin）

混在運用の活用例

ログイン画面のカスタマイズ

拡張スタイル

拡張スクリプト

配置後の確認

既存ユーザーの SSO 移行方法

SAML ログイン時のユーザー照合の仕組み

移行パターン

パターン A：LoginId がメールアドレスと同じ場合

パターン B：LoginId がメールアドレスと異なる場合

一括変更の方法

移行のおすすめ手順

RejectUnregisteredUser の活用

トラブルシューティング

まとめ

参考

方法 2：`Attributes` から除外して DB のデフォルト値を使う