オープンソースソフトウェアのシングルサインオン製品が求められる理由：OpenAMコンソーシアムがソースコード公開に至った狙いとは

多くの企業が複数の業務システムやアプリケーションを利用してビジネス活動を進めているため、IDとパスワードが増加している。またテレワークをはじめとした業務改革の推進により、クラウドサービスやモバイル利用者の利便性を損なうことなく自社のセキュリティポリシーを適応する仕組みが求められている。こうした課題を解決するのがシングルサインオン製品だ。中でも、オープンソースソフトウェアの「OpenAM」に改めて注目が集まっている。

[PR／＠IT]

PR

　昨今、多くの企業が複数の業務システムやアプリケーションを利用してビジネス活動を進めている。各アプリケーションやクラウドサービスを利用する際には、それぞれ個別にIDとパスワードを入力してログインする必要があるため、エンドユーザーにとっては業務効率の低下、また管理者にとっては運用負荷の増大という課題が顕在化してきている。また、最近ではテレワークをはじめとした業務改革の推進により、クラウドサービスやモバイル利用者の利便性を損なうことなく自社のセキュリティポリシーを適応する仕組みが求められている。

　こうした課題を解決するソリューションとして、ニーズが高まっているのがシングルサインオン（SSO）だ。シングルサインオンを導入することで、システムに一度ログインするだけで、全てのアプリケーションやクラウドサービスを利用することが可能になる。

　シングルサインオンを実現する製品は、すでに各ベンダーからさまざまなものがリリースされているが、その中でも、ベンダーに依存しないオープンソースソフトウェア（OSS）のシングルサインオン製品として提供されているのが「OpenAM」である。

長年のノウハウと信頼が蓄積されたオープンソースソフトウェア「OpenAM」

　2018年7月には、国内でOpenAMの維持、発展と普及促進を担うOpenAMコンソーシアムが、OpenAMのソースコードを一般公開し、共同開発を始めることが発表され、大きな注目を集めた。まずは、OpenAMベースの商用製品を販売しているオープンソース・ソリューション・テクノロジとオージス総研の2社が、ソースコードをマージするための作業を進めている。

　OpenAMは、OSSではあるが、最近出てきた製品とは異なり、その歴史は非常に長い。インターネットが普及した1990年台後半から提供されていた、Netscapeのシングルサインオンに端を発し、その後2005年に旧Sun MicrosystemsにOSS化されて「OpenSSO」となり、2010年からOpenAMの名称で開発が継承されている。

OpenAMの歴史

　「OpenAMにはシングルサインオンに関する長年のノウハウと信頼が蓄積され、高機能かつ高品質なオープンソースの統合認証製品となっている」と強調するのは、オープンソース・ソリューション・テクノロジ 代表取締役 チーフアーキテクトの小田切耕司氏だ。

オープンソース・ソリューション・テクノロジ 代表取締役 チーフアーキテクト 小田切耕司氏

　OpenAMの主な特長としては、シングルサインオンの方式として、エージェント方式、リバースプロキシ方式、代理認証方式、フェデレーション方式などを幅広くサポートしていることだ。特に、クラウドサービスとの認証連携に必須となるフェデレーション方式では、SAML、OpenID Connect、OAuthなどの業界標準プロトコルに対応している。これにより、クラウドとオンプレミス間、社内のシステムやアプリケーション間など、混在する複数の認証セグメントをつなぎ、統合的なシングルサインオンを実現できる。

　さらにOpenAMでは、モジュールを拡張することで、ID／パスワードによるシングルサインオンだけではなく、ICカードやワンタイムパスワード（OTP）、指紋認証や静脈認証といった生体認証なども併せて活用でき、セキュリティレベルをさらに高めることが可能となっている。

　そして、何よりこれらの充実したシングルサインオン機能がOSSとして提供されていること自体がOpenAMの大きな特長といえる。

オージス総研 事業開発本部 テミストラクトソリューション部 プロフェッショナルサービス第一チーム マネジャー 認証技術グループ 上席アーキテクト 八幡孝氏

　オージス総研 事業開発本部 テミストラクトソリューション部 プロフェッショナルサービス第一チーム マネジャー 認証技術グループ 上席アーキテクトの八幡孝氏は、次のように語る。

　「例えば、シングルサインオン製品を導入してトラブルが発生した際に、商用製品の場合は、ベンダーに改善依頼を出して、それが了承されるまでトラブル対応が進まない。一方、OSSの場合は、ソースコードが手元にあるため、トラブル対応を素早く開始できる。ソースコードからトラブルの状況を再現し、障害原因がどこにあるのかを調査、特定して、社内で迅速に修正対応を行うことが可能だ。また、ロジックの問題点が分かれば、その部分を修正してビルドし直すことで、トラブルの再発を防止できる」

海外ベンダーではなく、日本のOpenAMコンソーシアムが主体となることのメリット

　今回、OpenAMコンソーシアムでは、このOpenAMのソースコードを一般公開することで、OpenAMを利用している企業同士で脆弱（ぜいじゃく）性対策や機能拡張を共同で行えるようにした。

オープンソース・ソリューション・テクノロジ 技術部 エキスパート 辻口鷹耶氏

　この背景について、オープンソース・ソリューション・テクノロジ 技術部 エキスパートの辻口鷹耶氏は、次のように説明する。

　「OpenAMコンソーシアムは、OpenAMの日本での普及、発展を目指して2010年に発足し、ユーザー企業がOpenAMを継続的に利用できるようにさまざまな活動を行ってきた。しかし近年、ソースコードの公開頻度が低下し、トライアルも難しい状況になってきたことから、OSSとしての存続を不安視するユーザーも増えてきた。そこで今回、OpenAMコンソーシアムが主体となってソースコードを公開し、会員企業だけではなく一般コントリビューターも含めて共同で開発できる環境を整えていく」

　ベンダーではなく、OpenAMコンソーシアムがソースコードを公開することのメリットとしては、「負荷軽減」と「冗長化」の2点を挙げている。非営利団体のOpenAMコンソーシアムが主体となることで、ユーザー企業が開発に参加しやすくなる。共同開発する企業が増えれば増えるほど、開発リソースが増強し、開発やメンテナンスの負荷が軽減され、開発スピードや品質の向上にもつながる。

　「例えば、セキュリティパッチの対応については、共同でメンテナンスを行うことで、従来の半分の時間で終わらせることが可能になる。また、当社の導入事例で、特定条件でOpenAMが起動しない不具合を修正したケースがあったのだが、ソースコード公開後に、オープンソース・ソリューション・テクノロジでも同じ不具合を修正対応していたことが分かった。今後は、こうした重複した修正作業がなくなり、より効率的に開発を進めることができる」（八幡氏）

　冗長化という点では、バグ情報や技術情報、脆弱性情報、各種ツールのノウハウといった知見が各ベンダーで共有されるため、1ベンダーの動向に左右されることなく、OpenAMコンソーシアムとして活動する限りはソースコード公開が継続され、開発の冗長化を図ることができる。

　特に、脆弱性情報の共有については、他の開発者、利用者を考慮した公開方法を採用しており、「情報セキュリティ早期警戒パートナーシップにのっとって、IPA経由で脆弱性を公開していく。公開するタイミングは、JPCERT/CCが他の開発者に通知し、相談して決定する。パッチの提供は、GitHubで修正内容を公開。また、CVEを発行し、CVSSによる深刻度評価を行う」（辻口氏）という。

　この他にも、OpenAMコンソーシアムが運営する日本語のコミュニティーで共同開発ができるため、日本市場の要求に合わせた機能拡張にフォーカスしやすい点も見逃せないメリットといえるだろう。

　ソースコード公開後の共同開発の取り組みとして、オープンソース・ソリューション・テクノロジとオージス総研では、各社が開発したOpenAMのソースコードをマージする作業を進めているという。

共同開発における、各社の強み、現状、今後

　共同開発における各社の強みについて、オープンソース・ソリューション・テクノロジの小田切氏は、「当社は、OpenAMの前身であるOpenSSO時代の2008年からソリューションを提供してきた実績があり、OpenAMについても2010年から製品とサポートを提供してきた。また、OpenAM以外にも、SambaやOpenLDAPなど複数のOSS製品を扱っており、OpenAMの標準機能では要件を満たせない顧客向けにカスタマイズモジュールを提供してきたノウハウもある。こうした技術力を共同開発で発揮していきたい」と述べた。

オージス総研 事業開発本部 テミストラクトソリューション部 テクニカルサポートチーム 宮村英和氏

　オージス総研 事業開発本部 テミストラクトソリューション部 テクニカルサポートチームの宮村英和氏は、「当社は、2009年にOpenAMの取り扱いを開始し、2013年から商用製品として、OpenAMをベースにした統合認証ソリューション『ThemiStruct（テミストラクト）-WAM』を提供している。特に、大規模企業を中心に、個別にカスタムモジュールを開発してきた実績があり、ここで培った知見を生かして、共同開発に取り組んでいく。また、ThemiStruct-WAMの開発ではソースコード静的解析やOSSライセンス／脆弱性管理を徹底しており、そういった面からもOpenAMの品質向上に貢献できると自負している」とした。

　共同開発の現在の活動状況としては、ソースコード修正に関する運用ルールの大まかな策定が終了し、OpenAMのソースコードのマージを開始した段階だという。

　「開発環境については、2018年2月頃から、GitHubの標準的な開発フローを基に、コンソーシアムとして最適な形を検討してきた。そして、GitHubのMasterブランチをベースに、コンソーシアム会員の各企業が短いサイクルでビルド、テストを繰り返し、品質を高めていく開発フローを確立し、運用を開始している」（宮村氏）

GitHubを使ったOpenAMの開発フロー

　ソースコードを公開し、共同開発を開始した一方で、課題も浮き彫りになってきた。小田切氏は、「現在公開しているOpenAMのソースコードには、従来のライブラリとの依存関係が残っており、ソースコードだけではビルドできない。そのため、トライアルでの利用ができず、一般コントリビューターの参加が難しい状況になっている」と指摘する。

　このビルドの課題を解決し、コミュニティーの参加者を増やすべく、OpenAMコンソーシアムでは、まずはDockerイメージを公開し、誰でも容易にOpenAMのトライアルができる環境を整えていく。さらに、中期マイルストーンとして、依存ライブラリのフォークを完了し、ビルド手順を公開。最終的には、一般コントリビューターが自由にビルドできるよう、Mavenリポジトリを公開する計画だ。

　小田切氏は、「OpenAMコンソーシアムがソースコードを公開したことで、ユーザー企業は今後も安心してOpenAMの開発を続けていくことが可能になった。OpenAMコンソーシアムでは、ビルドの課題解決に取り組むとともに、引き続き機能追加や不具合修正、脆弱性対応を行っていく。また、標準技術についても、特定の業界やユースケースで使われるものを中心に、仕様改定や機能強化に対応し、OpenAMの活用領域を拡大していく」と意欲を見せていた。