NRI OpenStandia Advent Calendar 2020の25日目は、midPointがやらないことについて書きたいと思います。これまでmidPointをできるだけ知っていただくために記事を書いてきましたが、midPointができることだけ紹介しても、あまりよくわからないとも思います。あえてmidPointがやらないことを記載することでよりmidPointの位置づけが明確になれば嬉しいです。
midPointがやること
本題に入る前に改めてmidPointでできることをおさらいしてみます。初日にご紹介したThe Bookは初学者向けによくまとまった文章なのですが、なにぶん量が多くてなかなか面食らう方も多いかと思います。「The Bookを最初からじっくり読む時間はないけど、まずはさらっとmidPointの全体感を知りたい」そんな方におすすめなのがIntroductionのページです。midPoint開発者のRadovanもWikiにて「IntroductionのページがmidPointをスタートする最良の方法だ」と述べています。IntroductionのページではmidPointの主要機能について下記のように説明しています。
| 主要機能 | 説明 |
|---|---|
| User provisioning and deprovisioning | midPoint can automatically create and manage user accounts, groups, organizational units and so on. |
| Identity synchronization and reconciliation | midPoint can seamlessly synchronize several databases. It can make sure that the identity data are always up to date. |
| Identity management process automation | midPoint has a built-in engine that can drive approval of access requests. |
| Role-based access control (RBAC) | midPoint can automatically compute user privileges based on his membership in roles. MidPoint RBAC model is one of the most powerful models in the entire IDM field. |
| Management of identity-related parts of the enterprise security policy | midPoint can check password quality, maintain segregation of duties, and so on. |
| Support for security auditing and reporting | midPoint keeps an audit trail of all changes to user privileges. It has a built-in reporting engine to generate reports for identities collected from all the connected systems. |
| Non-intrusive integration using identity connectors | midPoint connectors are simple pieces of code that allows it to remotely connect to other system and manage identity data. The connectors are non-intrusive: the connected system does not need to be changed. |
| Management of organizational structure | its synchronization to other systems. |
| Identity governance | Management of complex policies that govern business aspect of identity management. |
midPointがやらないこと
さて本題のmidPointがやらないことですが、こちらはThe Bookの以下の章に記載があります。
https://docs.evolveum.com/book/practical-identity-management-with-midpoint.html#_what_midpoint_is_not
章名もWhat MidPoint Is Not。ド直球ですね。
こちらもこのページのサマリをご紹介したいと思います。
最初の4パラグラフまでは認証に関する記述をしています。
認証サーバではない、ゆえにSSOサーバでもないことについて明記しています。
こちらについては少しでもmidPointについてご存じの方でもあれば特に違和感はないかなと思います。
第5パラグラフからは認可に関する記述をしています。
認可サーバについてはよく混乱を招くとしています。ここは原文を引用して翻訳してみたいと思います。
One of the things that seems to be shrouded in a lot of confusion is authorization. To get the record straight from the beginning: midPoint is not an authorization server. It is not a policy decision point (PDP) and it definitely is not a policy enforcement point (PEP). You cannot rip authorization out of your application and just “use midPoint for that”. That does not work.
よく混乱の元になるのがauthorizationである。始めにはっきりさせておくと、midPointは認可サーバではない。midPointはpolicy decision point (PDP)ではないし、policy enforcement point (PEP)でもない。アプリケーションから認可を取り除くことはできないし、そのためにmidPointを利用することもできない。それはうまくいかないのだ。
You can think of midPoint as a policy management point (PMP). MidPoint has a lot of sophisticated authorization-related logic inside its core. But that logic is not designed to answer questions such as "Is subject S authorized to execute operation O on object X?". MidPoint logic is different. MidPoint is not concerned with making authorization decisions. It is concerned about managing the authorization policies. MidPoint sets up the authorization policies in target applications. And the applications evaluate these policies themselves.
midPointをpolicy management point (PMP)として捉えてもらえばよい。midPointは多くの洗練された認可に関連したロジックをその内部に備えている。ただし、そのロジックは"主体SはオブジェクトXに対してオペ―ションOを実行することを認可されているか"という問いに答えるものではない。midPointのロジックは異なる。midPointは認可の決定を下すことに関心があるわけではなく、その認可の決定を下すためのポリシーそのものの管理に関心があるのだ。
This is a much more efficient and more reliable method. Unlike authentication, the authorizations decisions are done all the time. Authorization is evaluated at least once per every request. If the application makes these decision internally then there is no need to a round-trip to the authorization server. Performance is significantly increased. And there is no single point of failure. MidPoint failure will not interrupt authorization flow because the application has all the data inside. One less component to cause a failure. And still, the policies are centrally managed by midPoint. When a policy changes midPoint updates all the affected applications. You get all the benefits without the usual drawbacks.
これは効率的で信頼性の高い方法である。認証と異なり、認可の決定は常に行われる必要がある。認可は少なくともリクエストごとに毎回評価される。もしアプリケーションが認可の決定を内部で行えば、認可サーバへのラウンドトリップが必要なくなる。パフォーマンスは大いに改善するだろう。また、認可サーバが単一障害点となる心配もない。その上、ポリシーはmidPointにより中央管理されている。ポリシーが変更された際には、midPointが関連するアプリケーションに対してUPDATEをかける。特に不利益なく利点を享受できるのである。
いかがでしょうか？
"ポリシー"という言葉にmidPointの設計哲学が込められていることが理解できると思います。
midPointを適用する際には上記設計思想があることを念頭にしておく必要があります。
Keycloakにおけるアプローチ
Keycloakではこのあたりについてどのようなアプローチなのでしょうか。KeycloakのマニュアルではAuthorization Servicesという章があり、Keycloakにおける実装はここで詳細に解説されています。一言でいうと、Keycloakは認可についてもプロダクトのカバー範囲と捉えており、Keycloak Adaptorにより機能を提供しています。
図を見るとわかるとおり、PAP、PDP、PEP、PIPをKeycloakのカバー範囲としています。
ID管理/認証システム導入の理想と現実
ID管理、認証、そして、認可について、実プロジェクトへの適用を考えると、なかなかその境界線であったり、役割分担であったりに悩むことがあります。このあたりについて、わかりやすく解説されている日本語ドキュメントがありましたので紹介させて頂きます。
ID管理/認証システム導入の理想と現実
https://www.slideshare.net/naohiro.fujie/id-69777892
OpenID Foundationの活動などで有名な富士榮さんの発表資料です。
2016年の資料になりますが、どの部分も今でもとても参考になります。
特に、今回の、ID管理、認証、認可の役割分担、担当範囲という意味ですと、P.9、P.10あたりが参考になるかと思います。
最後に
途中から若干midPointの話でなくなってしまいましたが、midPointのカバー範囲について少しでも理解が参考になる部分があったら嬉しいです。なお、OpenStandiaでは以下のようなソリューションにてシステム配置することが多いです。
- ID管理&ガバナンスシステムをmidPoint
- 統合認証システムをKeycloak
- アプリケーションの認可はKeycloakアダプタやリバプロ（Apache、NGINX、Keycloak Gatekeeper）
OpenStandiaではこの領域をトータルでサービス提供するソリューションである「OpenStandia KAID」を2020年にローンチしています。こちらについてはOpenStandiaサイトで紹介していますのでこちらもぜひウォッチをお願いします。
今年もOpenStandiaのAdvent Calendarにお付き合いくださりありがとうございました。
2021年もどうぞ宜しくお願いいたします。