OSS活用ソリューション ThemiStruct （テミストラクト） シリーズ概要

いまさら聞けない「シングルサインオンの

基本」と、社員１万人の大企業における

OpenAM導入事例紹介

～Webアプリケーションに手をいれることなく、

認証連携を実現する方法～

株式会社オージス総研

テミストラクトソリューション部

会社概要

代表者：

代表取締役社長 平山 輝

設 立：

1983年6月29日

資本金：

4億円

（大阪ガス株式会社100%出資）

事業内容：

システム開発、プラットフォームサービス、

コンピュータ機器･ソフトウェアの販売、

コンサルティング、研修・トレーニング

主な事業所

本 社：

大阪府 大阪市西区千代崎3-南2-37 ICCビル

東京本社：

東京都 港区港南2-15-1 品川インターシティA棟

名古屋オフィス： 愛知県 名古屋市中区錦1-17-13 名興ビル

売上実績：

567億円

（連結）

_298億円

（単体）

(2013年度)

従業員数：

3,104名

（連結）

1,283名

（単体）

関連会社：

さくら情報システム（株）、 （株）宇部情報システム、 （株）システムアンサー、

OGIS International,Inc、上海欧計斯軟件有限公司（中国）

オージス総研グループ 売上構成比

（連結）

_{取得許可認定}

株式会社オージス総研



シングルサインオンの基礎



導入事例



テミストラクトの紹介

シングルサインオンとは

シングルサインオンでない状態

シングルサインオン導入後

クラウドサービス

グループウェア

業務システム

クラウドサービス

グループウェア

業務システム

各システムに

都度ログイン・・・

SSO

１回のログインで

アクセス可能！

なぜ、シングルサインオンが必要なのか 其の壱

ユーザーにとって・・・

システムが増える ＝ 業務は楽になる + 認証は不便になる

このシステムは

このパスワードで・・・

ID/パスワードが増える

昨日もパスワード

変更したのに・・・

システム毎にパスワード変更

またログイン画面か・・・

システム毎にログイン

・ログインは

一回でOK！

・ID/パスワードは

一個覚えればOK！

・パスワード変更は

一カ所でOK！

つまり、

ユーザの利便性が向上

する！

シングルサインオンを実現すると・・・

なぜ、シングルサインオンが必要なのか 其の弐

認証・認可の実装は、意外と大変。

セキュアなシステムかどうかは、システム開発者の技量に依存する。

・SSOシステムに任せれば、

アクセス制御の一元管理

が可能。

⇒既存システムへの

アプリ単位のアクセス制御を一カ所で管理

できる。

⇒新規システムを開発しても、

アクセス制御の実装が楽

になる。

・認証の

セキュリティレベル統一

が可能。

つまり、

セキュリティが向上し、開発/運用コスト削減に役立つ

！

アクセス制御が未実装

制御ルールがバラバラ

あれ？ちゃんと制御できてる？

設定ミスしたかな・・・

シングルサインオンを実現すると・・・

他部署の機密文書が

参照できてしまう・・・

製造部

営業部用

アプリ

なぜ、シングルサインオンが必要なのか 其の参

セキュリティや運用の観点では・・・

システムが増える = セキュリティリスクUP + 運用負荷UP

・ID/パスワードは一個だから、管理しやすい。

⇒

パスワード漏えいを回避

するために、

十分な対策

をとれる。

・

認証ログを一カ所で管理

でき、

監査対象を一つ

にできる。

⇒

運用がシンプル

になる。

つまり、

セキュリティが向上し、運用負荷が下がる！

パスワード多すぎて

覚えられないから

付箋にメモしておこう

セキュリティリスク

--- --- --- ID 12345 PW abcde

♪

運用負荷

全アプリケーションの

ログ管理なんてできない！！

シングルサインオンを実現すると・・・

シングルサインオンで目指すべき形

「社内アプリ」と「クラウドサービス」の両方を利用する構成で

・ユーザの利便性向上

・セキュリティ向上

を実現するシングルサインオンが、

将来目指すべき形

。

SSO

RP

セキュリティ強化は

SSOシステムだけやればOK

_{認証は一回だけ}

アプリの認証に

パスワードを使わない



シングルサインオン実現のための「3ステップ」

シングルサインオン実現方式

ID/パスワード ワンタイム パスワード デスクトップ SSO

Step1

エージェント型？ リバースプロキシ型？ SAML型？

Step2

Step3

認証方法を決める

連携方式を決める

SSO

_？

SSO

_？

アプリのログイン方式

を決める

HTTPヘッダ連携？ Cookie連携？ 代理認証？



ユーザーが行う認証の方法を決定する

シングルサインオン実現方式 ～認証方法を決める～

「

セキュリティリスクの高さ

」を考慮し、

「

利便性

」・「

セキュリティ

」・「

コスト

」

のバランスを考えて決定する

社内からしかアクセス

できないのに、複雑な認証方法

社外から重要情報にアクセス

_{するのに、簡単な認証方法}

セキュアにしたはいいけど、

導入コストが高すぎる

ワンタイム

パスワード

統合Windows

認証

社外からは

多要素認証

証明書認証

ID/パスワード

シングルサインオン実現方式 ～認証方法を決める～

証明書認証

認証サーバ

たとえば、

・社内ユーザにとっての利便性を低下させたくない

・社外からアクセスには、セキュリティを高めたい

・社外からのアクセスのみ多要素認証させる

・多要素認証に証明書認証を使う

• ブラウザにインストールしたクライ

アント証明書をもとに、端末を認証

する。

シングルサインオン実現方式 ～認証方法を決める～

たとえば、

・社内からのアクセスしかない（社外公開していない）

・とにかく便利にしたい

・統合Windows認証にする

統合Windows認証

認証サーバ

① Windowsドメインログオン

ActiveDirectory

② ドメインログオン情報を

使って認証（自動処理）

• Windowsドメインにログオンして

いれば、システムへのログインを自

動で行う認証方法

• ユーザがID/パスワードを入力する

のは、ドメインログオン時のみ。

シングルサインオン実現方式 ～連携方式を決める～



SSO対象アプリケーションと認証サーバをどのように連携

するかを決定する

社内アプリ

アプリアクセスの手前で認証

・エージェント型

・リバースプロキシ型

クラウドサービス

認証情報を安全な方法で渡す

・フェデレーション型

SSO

SSO

シングルサインオン実現方式 ～連携方式を決める～

エージェント型

Webサーバー、アプリケーションサーバーに直接エージェントを導入する方法。

エージェントごとにSSOサーバーとの通信が発生する。

SSO対象 アプリ

A

SSO対象 アプリ

B

SSO

利用者

ログイン

SSO対象アプリに

アクセス

SSO対象アプ

リに認証済み

情報を連携

①

②

③

認証済みであれば

アプリを利用可能

④

シングルサインオン実現方式 ～連携方式を決める～

リバースプロキシ型

リバースプロキシサーバーにエージェントを導入し、アプリケーションへのアク

セスをリバースプロキシサーバー経由にする方法。

SSOサーバーとのやりとりをリバースプロキシサーバーに任せる。

SSO対象 アプリ

A

SSO対象 アプリ

B

リバースプロキシ

SSO

利用者

アプリ A 用の

仮想ホスト

OR

仮想パス

アプリ B 用の

仮想ホスト

OR

仮想パス

ログイン

リバースプロキシ

サーバーにアクセス

SSO対象アプ

リに認証済み

情報を連携

①

②

③

認証済みであればSSO対

象アプリに接続

④

シングルサインオン実現方式 ～連携方式を決める～

フェデレーション型

安全な方法でクラウドサービスとのSSOを実現するために、SAMLやOpenID

Connectなどのフェデレーション（認証連携）用のプロトコルを利用する方式。

利用者

利用者情報 なまえ 利用者 メール [email protected] 電話 0x0-1234-5678 利用者情報 name themistruct mail [email protected]

address Tokyo Japan

SSO

クラウドサービス あらかじめ 属性情報が 一部連携 されている サービス利用開始

①

HTTP Redirect ＆ POST

②

POSTデータは ユーザー属性の やり取り開始の 手続きにあたる ユーザー認証

③

HTTP Redirect ＆ POST

④

POSTデータはユーザー 属性にあたる （この場合は“メール”情報） SSO成功

SAMLプロトコルを利用した認証連携の流れ

シングルサインオン実現方式 ～アプリのログイン方式を決める～



SSO対象アプリケーション側でユーザーを認証する方法を

決定します。

アプリケーション側の

認証方法を改修可能か

属性情報連携方式

代理認証方式

SSOサーバーから受け取った情報をも

とに認証する

・HTTPヘッダ連携

・Cookie連携

アプリの認証方法を再現し、ユーザー

の代わりにアプリ認証を行う

・Basic認証

・From認証

YES

NO

シングルサインオン実現方式 ～アプリのログイン方式を決める～

代理認証方式

ユーザーが初めにログインする際にアクセスするURL（代理認証用URL）にて、

ID/パスワードを代わりに送信し、Cookie等の認証済み情報を取得する。

リバースプロキシ

代理認証用URL

アプリ用の

仮想ホスト

OR

仮想パス

SSO

属性情報を

エージェントに

連携

②

代理認証用

URLにアクセス

①

ユーザーの代わりに

ID/パスワードを送信

③

アプリから取得した

Cookieをブラウザに

セットし、ログイン後

URLにリダイレクト

④



シングルサインオンを導入すると、

• ユーザの利便性が向上する

• セキュリティが向上する



シングルサインオンを実現するためには、

• 認証方法を決める

• 連携方式を決める

• アプリのログイン方式を決める



連携方式には

• 社内アプリでは「エージェント型」「リバースプロキシ型」がある

• クラウドサービスは「フェデレーション型」でSSO可能



代理認証方式で

• アプリケーション改修せずにシングルサインオンできる

シングルサインオンの基礎 ～まとめ～

プロジェクトの概要

概要

： サービス業様 認証基盤構築プロジェクト

バラバラの認証方式のアプリケーションに対して、

代理認証方式によりシングルサインオンを実現

ユーザー数

： 約 10,000 ユーザー（社外/社内）

接続アプリ数 ： 約 30 システム

ポイント

： 社内ユーザーは統合Windows認証を利用可能とする。

外部サーバー（勤務日確認システム）から取得した、ア

クセスしてきたユーザが勤務日かどうかの情報をもとに、

アクセス判定を行う仕組みを実装する。

プロジェクトでの課題

アプリ担当者が不明だったりして、仕様がわからない。つまり、

「アプリの改修はできない！」

「でもシングルサインオンは実現したい！」

リバースプロキシ型/代理認証方式を採用

実は…

リバースプロキシ型/代理認証方式は、

やってみるまでできるかわからない。

・リバースプロキシ型

コンテンツ変換がうまくいかない（画面が正常に表示されない）

場合がある。

・代理認証方式

アプリが複雑な認証方法をしている等、代理認証の実装に

時間がかかるパターンが存在する。



各アプリケーションで認証の仕様が統一されていない



SSOログイン用のID/パスワードとは異なるID/パスワード

を使って代理認証を実現

• 認証用DBに代理認証用のID/パスワードを暗号化してセット

• 代理認証時はパスワードを復号化してアプリに送信

構築のポイント

代理認証を実現するために実施すること

アプリケーション

認証仕様の調査

代理認証を設定

接続検証

を、アプリの数分実施



特殊な認可方法の実装

• アクセスユーザが勤務日かどうかによってアクセス制御する

 外部サーバにユーザ情報を問い合わせてアクセス制御を行うモ

ジュールを新規に開発して対応。



統合Windows認証モジュールのバグ修正

• クライアント側のOS/ブラウザの組み合わせによっては、正常に動

作しないバグが存在

 OGISでバグ修正を実施

構築のポイント

OSSであるOpenAMだからこそ

実現できた

認証基盤

連携先システム

社外ユーザ

社内ユーザ

外部RPサーバ 内部RPサーバ Active Directory SSOサーバ 内部専用アプリケーション 外部公開アプリケーション

DMZ

内部ネットワーク

インターネット

最終的なシステム構成

ThemiStruct-WAM

ID/パスワード認証

Windows統合認証

代理認証

代理認証

ユーザーがアクセス可能

かどうかを問い合わせる

勤務日確認システム

ThemiStruct のご紹介

ThemiStructはシステムの “連携” を実現します。

シングル サインオン ID 配布・管理 サーバー 監視 ワンタイム パスワード 電子証明書 配布・管理 ワーク フロー

ThemiStructは企業の様々なシステムの“連携”を実現する６つのIT基盤ソ

リューションから成っています。企業を取り巻く様々なIT環境の変化と要

求にお応えできるよう、日々進化し続けています。

社内とクラウドをシームレスに

つなぐシングルサインオン

電子証明書の「発行」と「管理」を

シンプルに実現



OSSであるOpenAMがベースのソリューション

• シングルサインオンを実現する機能が完備されている

• 機能拡張のためのフレームワークが提供されていて、拡張性が高い

 フレームワークで実装できなく個別実装でも、取り込みやすい



ThemiStruct-WAMだからこそ

• OpenAMと組み合わせて使えるモジュールが豊富

• 導入実績が豊富で、具体的な構築イメージが提示できる

• OpenAMはもちろん、ThemiStruct-WAM独自の部分全てにおいて

サポートサービスが充実している

ThemiStruct-WAMの特徴

おわりに

シングルサインオンの目指す形は、

「アプリで認証・認可をしない」

⇒アプリにはクレデンシャルを持たせない

どうしても改修できないアプリは、存在する

より最適な方法で、

代理認証方式によるシングルサインオンを実現

おわりに