20141111 themi struct

CCooppyyrriigghhtt©© 2 200131 4 O GOIGS-IRSI- RCIo .C, Lot.,d .L tAdl.l r iAglhl trsi grehstesr vreedse. rved.
いまさら聞けない「シングルサインオンの
基本」と、社員１万人の大企業における
OpenAM導入事例紹介
～Webアプリケーションに手をいれることなく、
認証連携を実現する方法～
株式会社オージス総研
テミストラクトソリューション部

Copyright© 2013 OGIS-RI Co., Ltd. All rights reserved.
2
会社概要代表者：代表取締役社長平山輝設立： 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、上海欧計斯軟件有限公司（中国）オージス総研グループ売上構成比（連結）
取得許可認定
株式会社オージス総研

シングルサインオンの基礎
導入事例
テミストラクトの紹介
3
アジェンダ

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

CCooppyyrriigghhtt©© 2 200131 4 O GOIGS-IRSI- RCIo .C, Lot.,d .L tAdl.l r iAglhl trsi grehstesr vreedse. rved. 5
シングルサインオンとは
シングルサインオンでない状態シングルサインオン導入後
クラウドサービス
グループウェア
業務システム
グループウェア
業務システム
各システムに
都度ログイン・・・
SSO
１回のログインで
アクセス可能！

なぜ、シングルサインオンが必要なのか其の壱
ユーザーにとって・・・
システムが増える＝業務は楽になる + 認証は不便になる
このシステムは
このパスワードで・・・
ID/パスワードが増える
昨日もパスワード
変更したのに・・・
システム毎にパスワード変更
またログイン画面か・・・
システム毎にログイン
・ログインは一回でOK！
・ID/パスワードは一個覚えればOK！
・パスワード変更は一カ所でOK！
つまり、ユーザの利便性が向上する！
シングルサインオンを実現すると・・・

なぜ、シングルサインオンが必要なのか其の弐
認証・認可の実装は、意外と大変。
セキュアなシステムかどうかは、システム開発者の技量に依存する。
・SSOシステムに任せれば、アクセス制御の一元管理が可能。
⇒既存システムへのアプリ単位のアクセス制御を一カ所で管理できる。
⇒新規システムを開発しても、アクセス制御の実装が楽になる。
・認証のセキュリティレベル統一が可能。
つまり、セキュリティが向上し、開発/運用コスト削減に役立つ！
アクセス制御が未実装制御ルールがバラバラ
あれ？ちゃんと制御できてる？
設定ミスしたかな・・・
他部署の機密文書が
参照できてしまう・・・
製造部
営業部用
アプリ

なぜ、シングルサインオンが必要なのか其の参
セキュリティや運用の観点では・・・
システムが増える = セキュリティリスクUP + 運用負荷UP
・ID/パスワードは一個だから、管理しやすい。
⇒パスワード漏えいを回避するために、十分な対策をとれる。
・認証ログを一カ所で管理でき、監査対象を一つにできる。
⇒運用がシンプルになる。
つまり、セキュリティが向上し、運用負荷が下がる！
パスワード多すぎて
覚えられないから
付箋にメモしておこう
セキュリティリスク
---------------
---------------
---------------
ID 12345
PW abcde
♪
運用負荷
全アプリケーションの
ログ管理なんてできない！！

シングルサインオンで目指すべき形
「社内アプリ」と「クラウドサービス」の両方を利用する構成で
・ユーザの利便性向上
・セキュリティ向上
を実現するシングルサインオンが、将来目指すべき形。
RP SSO
セキュリティ強化は
SSOシステムだけやればOK 認証は一回だけ
アプリの認証に
パスワードを使わない

シングルサインオン実現のための「3ステップ」
10
シングルサインオン実現方式
ID/パスワード
ワンタイム
パスワード
デスクトップ
SSO
Step1
エージェント型？
リバースプロキシ型？
SAML型？
Step2
Step3
認証方法を決める
連携方式を決める
SSO
？
SSO
？
アプリのログイン方式を決める
HTTPヘッダ連携？
Cookie連携？
代理認証？

ユーザーが行う認証の方法を決定する
11
シングルサインオン実現方式～認証方法を決める～
「セキュリティリスクの高さ」を考慮し、
「利便性」・「セキュリティ」・「コスト」
のバランスを考えて決定する
社内からしかアクセスできないのに、複雑な認証方法
社外から重要情報にアクセス
するのに、簡単な認証方法
セキュアにしたはいいけど、導入コストが高すぎる
ワンタイム
パスワード
統合Windows
認証
社外からは
多要素認証
証明書認証
ID/パスワード

証明書認証
認証サーバ
12
たとえば、
・社内ユーザにとっての利便性を低下させたくない
・社外からアクセスには、セキュリティを高めたい
・社外からのアクセスのみ多要素認証させる・多要素認証に証明書認証を使う
•ブラウザにインストールしたクライアント証明書をもとに、端末を認証する。

13
たとえば、
・社内からのアクセスしかない（社外公開していない）
・とにかく便利にしたい
・統合Windows認証にする
統合Windows認証
認証サーバ
① Windowsドメインログオン
ActiveDirectory
② ドメインログオン情報を
使って認証（自動処理）
•Windowsドメインにログオンしていれば、システムへのログインを自動で行う認証方法
•ユーザがID/パスワードを入力するのは、ドメインログオン時のみ。

CCooppyyrriigghhtt©© 2 200131 4 O GOIGS-IRSI- RCIo .C, Lot.,d .L tAdl.l r iAglhl trsi grehstesr vreedse. rved.
シングルサインオン実現方式～連携方式を決める～
14
 SSO対象アプリケーションと認証サーバをどのように連携
するかを決定する
社内アプリ
アプリアクセスの手前で認証
・エージェント型
・リバースプロキシ型
認証情報を安全な方法で渡す
・フェデレーション型
SSO
SSO

15
エージェント型
Webサーバー、アプリケーションサーバーに直接エージェントを導入する方法。
エージェントごとにSSOサーバーとの通信が発生する。
SSO対象
アプリ
A
SSO対象アプリ B
SSO
利用者
ログイン
SSO対象アプリにアクセス
SSO対象アプリに認証済み情報を連携
①
②
③
認証済みであれば
アプリを利用可能
④

16
リバースプロキシ型
リバースプロキシサーバーにエージェントを導入し、アプリケーションへのアクセスをリバースプロキシサーバー経由にする方法。 SSOサーバーとのやりとりをリバースプロキシサーバーに任せる。
SSO対象
アプリ
A
SSO対象
アプリ
B
リバースプロキシ
SSO
利用者
アプリ A 用の
仮想ホスト
OR
仮想パス
アプリ B 用の
仮想ホスト
OR
仮想パス
ログイン
サーバーにアクセス
SSO対象アプリに認証済み情報を連携
①
②
③
認証済みであればSSO対象アプリに接続
④

17
フェデレーション型
安全な方法でクラウドサービスとのSSOを実現するために、SAMLやOpenID Connectなどのフェデレーション（認証連携）用のプロトコルを利用する方式。
利用者
利用者情報
なまえ
利用者
メール
riyousha@ogis-ri.jp
電話
0x0-1234-5678
利用者情報
name
themistruct
mail
riyousha@ogis-ri.jp
address
Tokyo Japan
SSO
あらかじめ
属性情報が
一部連携
されている
サービス利用開始
①
HTTP Redirect
＆
POST
②
POSTデータは
ユーザー属性の
やり取り開始の
手続きにあたる
ユーザー認証
③
HTTP Redirect
＆
POST
④
POSTデータはユーザー
属性にあたる
（この場合は“メール”情報）
SSO成功
SAMLプロトコルを利用した認証連携の流れ

シングルサインオン実現方式～アプリのログイン方式を決める～
18
SSO対象アプリケーション側でユーザーを認証する方法を決定します。
アプリケーション側の
認証方法を改修可能か
属性情報連携方式
代理認証方式
SSOサーバーから受け取った情報をもとに認証する
・HTTPヘッダ連携
・Cookie連携
アプリの認証方法を再現し、ユーザーの代わりにアプリ認証を行う
・Basic認証
・From認証
YES
NO

シングルサインオン実現方式～アプリのログイン方式を決める～
19
代理認証方式
ユーザーが初めにログインする際にアクセスするURL（代理認証用URL）にて、 ID/パスワードを代わりに送信し、Cookie等の認証済み情報を取得する。
代理認証用URL
アプリ用の
仮想ホスト
OR
仮想パス
SSO
属性情報を
エージェントに連携
②
代理認証用
URLにアクセス
①
ユーザーの代わりに ID/パスワードを送信
③
アプリから取得した Cookieをブラウザにセットし、ログイン後 URLにリダイレクト
④

シングルサインオンを導入すると、
•ユーザの利便性が向上する
•セキュリティが向上する
シングルサインオンを実現するためには、
•認証方法を決める
•連携方式を決める
•アプリのログイン方式を決める
連携方式には
•社内アプリでは「エージェント型」「リバースプロキシ型」がある
•クラウドサービスは「フェデレーション型」でSSO可能
代理認証方式で
•アプリケーション改修せずにシングルサインオンできる
20
シングルサインオンの基礎～まとめ～

21
事例紹介

22
プロジェクトの概要
概要
：
サービス業様認証基盤構築プロジェクト
バラバラの認証方式のアプリケーションに対して、
代理認証方式によりシングルサインオンを実現
ユーザー数
：
約 10,000 ユーザー（社外/社内）
接続アプリ数
：
約 30 システム
ポイント
：
社内ユーザーは統合Windows認証を利用可能とする。
外部サーバー（勤務日確認システム）から取得した、アクセスしてきたユーザが勤務日かどうかの情報をもとに、アクセス判定を行う仕組みを実装する。

23
プロジェクトでの課題
アプリ担当者が不明だったりして、仕様がわからない。つまり、「アプリの改修はできない！」「でもシングルサインオンは実現したい！」
リバースプロキシ型/代理認証方式を採用
実は…
リバースプロキシ型/代理認証方式は、
やってみるまでできるかわからない。
・リバースプロキシ型
コンテンツ変換がうまくいかない（画面が正常に表示されない）
場合がある。
・代理認証方式
アプリが複雑な認証方法をしている等、代理認証の実装に
時間がかかるパターンが存在する。

各アプリケーションで認証の仕様が統一されていない
SSOログイン用のID/パスワードとは異なるID/パスワードを使って代理認証を実現
•認証用DBに代理認証用のID/パスワードを暗号化してセット
•代理認証時はパスワードを復号化してアプリに送信
24
構築のポイント
代理認証を実現するために実施すること
アプリケーション認証仕様の調査
代理認証を設定
接続検証
を、アプリの数分実施

特殊な認可方法の実装
•アクセスユーザが勤務日かどうかによってアクセス制御する
外部サーバにユーザ情報を問い合わせてアクセス制御を行うモジュールを新規に開発して対応。
統合Windows認証モジュールのバグ修正
•クライアント側のOS/ブラウザの組み合わせによっては、正常に動作しないバグが存在
OGISでバグ修正を実施
25
構築のポイント
OSSであるOpenAMだからこそ
実現できた

CCooppyyrriigghhtt©© 2 200131 4 O GOIGS-IRSI- RCIo .C, Lot.,d .L tAdl.l r iAglhl trsi grehstesr vreedse. rved.2 6
認証基盤連携先システム
社外ユーザ
社内ユーザ
外部RPサーバ
内部RPサーバ
Active Directory
SSOサーバ
内部専用アプリケーション
外部公開アプリケーション
DMZ
内部ネットワーク
インターネット
最終的なシステム構成
ThemiStruct-WAM
ID/パスワード認証
Windows統合認証
代理認証
代理認証
ユーザーがアクセス可能
かどうかを問い合わせる
勤務日確認システム

27
ThemiStruct のご紹介

28
ThemiStruct のご紹介
ThemiStructはシステムの “連携” を実現します。
シングル
サインオン
ID
配布・管理
サーバー
監視
ワンタイムパスワード
電子証明書
配布・管理
ワークフロー
ThemiStructは企業の様々なシステムの“連携”を実現する６つのIT基盤ソリューションから成っています。企業を取り巻く様々なIT環境の変化と要求にお応えできるよう、日々進化し続けています。
社内とクラウドをシームレスに
つなぐシングルサインオン
電子証明書の「発行」と「管理」を
シンプルに実現

OSSであるOpenAMがベースのソリューション
•シングルサインオンを実現する機能が完備されている
•機能拡張のためのフレームワークが提供されていて、拡張性が高い
フレームワークで実装できなく個別実装でも、取り込みやすい
ThemiStruct-WAMだからこそ
•OpenAMと組み合わせて使えるモジュールが豊富
•導入実績が豊富で、具体的な構築イメージが提示できる
•OpenAMはもちろん、ThemiStruct-WAM独自の部分全てにおいてサポートサービスが充実している
29
ThemiStruct-WAMの特徴

おわりに
30
シングルサインオンの目指す形は、
「アプリで認証・認可をしない」
⇒アプリにはクレデンシャルを持たせない
どうしても改修できないアプリは、存在する
より最適な方法で、
代理認証方式によるシングルサインオンを実現

31
おわりに
ご清聴ありがとうございました。

20141111 themi struct

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a 20141111 themi struct

Semelhante a 20141111 themi struct (20)

Mais de マジセミ by （株）オープンソース活用研究所

Mais de マジセミ by （株）オープンソース活用研究所 (9)

20141111 themi struct