どうも、WEBサービス開発グループの石川です。
弊社では2年ほど前からAtlassian製品を利用していまして、私がその管理者として導入から運用まで行っています。
Atlassian製品を導入する前も後も、Atlassian User Groupには大変お世話になっていて、どこかで恩返しができればと思っていたのですが、ようやく叶いました。
第24回 Tokyo Atlassian ユーザーグループ @eureka #augj – connpass
Atlassian Crowdという統合ID管理の仕組みを使って、JIRA/Confluence/BitbucketServer/Subversionの認証とユーザー管理をまとめてSSOにもした話と、申請業務を利用者に権限を委譲（安全性は担保）して運用工数削減した話になっています。
ご興味があれば以下でスライドを公開していますのでご覧ください。
資料の補足
いくつか時間の関係と話が横に逸れてしまうため省略した部分について補足します。
グループの利用法
グループにはいくつか役割を持たせているものと、完全に自由なものの2種類prefixで分けたりして管理しています。
- xxx-users, xxx-developers, xxx-administrators
- Atlassian製品のライセンスに関わるグループ
- xxx-groups
- LDAPにいるユーザーを分類するグループ（社員のみ入ったグループもここ）
- team-xxxx
- プロジェクトごとなどで自由に作れるグループ
- xxxxの部分がSubversionのリポジトリ名と一緒だった場合、リポジトリの操作権限を得られる
- Crowd-Clientからグループメンバーの操作ができるのはこのグループ帯だけ
LDAPが空になったときの対策
LDAPと完全同期しているDirectoryにいるユーザーと、そのDirectoryに作ったグループを各アプリケーションに同期させていたので、LDAPの状態異常をダイレクトに食らってしまうのが問題でした。
最善とは言い難い解決策ですが、認証だけLDAPに問い合わせる Delegated Authentication Directory を新たに作成して、LDAP Directoryにあった変更を Delegated Authentication Directory へCrowd APIを使って自力で同期することで制御しました。
- LDAP DirectoryにLDAPの情報を同期
- LDAP DirectoryとDelegated Authentication Directoryを比較してLDAP Directoryに新規追加されたユーザー、削除されたユーザーを検出
- 新規追加されたユーザーはDelegated Authentication Directoryにユーザー情報を追加
- 削除されたユーザーがn人以上の場合は強制終了してエラー出力
- 削除されたユーザーをDelegated Authentication Directoryから無効化
n件以下をオペミスで削除してしまうというシーンは発生確率が低いと思われるため対処していません。
前回と違ってユーザーを削除ではなく無効化にしたため、これでプライマリキーが変わることもなく全停止してバックアップから復旧する必要もなくなりました。
