20141111 themi struct

Copyright© 2013 OGIS-RI Co., Ltd. All rights reserved. Copyright© 2014 OGIS-RI Co., Ltd. All rights reserved.

いまさら聞けない「シングルサインオンの基本」と、社員１万人の大企業における

OpenAM導入事例紹介

～Webアプリケーションに手をいれることなく、認証連携を実現する方法～

株式会社オージス総研

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

Copyright© 2013 OGIS-RI Co., Ltd. All rights reserved. Copyright© 2014 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

アジェンダ


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


シングルサインオンとは

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

クラウドサービス

グループウェア

業務システム


グループウェア

業務システム

各システムに都度ログイン・・・

SSO

１回のログインでアクセス可能！


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

ユーザーにとって・・・システムが増える＝業務は楽になる + 認証は不便になる

このシステムはこのパスワードで・・・

ID/パスワードが増える

昨日もパスワード変更したのに・・・

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

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

システム毎にログイン

・ログインは一回でOK！・ID/パスワードは一個覚えればOK！・パスワード変更は一カ所でOK！つまり、ユーザの利便性が向上する！

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


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

認証・認可の実装は、意外と大変。セキュアなシステムかどうかは、システム開発者の技量に依存する。

・SSOシステムに任せれば、アクセス制御の一元管理が可能。 ⇒既存システムへのアプリ単位のアクセス制御を一カ所で管理できる。 ⇒新規システムを開発しても、アクセス制御の実装が楽になる。・認証のセキュリティレベル統一が可能。つまり、セキュリティが向上し、開発/運用コスト削減に役立つ！

アクセス制御が未実装制御ルールがバラバラ

あれ？ちゃんと制御できてる？設定ミスしたかな・・・


他部署の機密文書が参照できてしまう・・・

製造部営業部用

アプリ


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

セキュリティや運用の観点では・・・システムが増える = セキュリティリスクUP + 運用負荷UP

・ID/パスワードは一個だから、管理しやすい。 ⇒パスワード漏えいを回避するために、十分な対策をとれる。・認証ログを一カ所で管理でき、監査対象を一つにできる。 ⇒運用がシンプルになる。つまり、セキュリティが向上し、運用負荷が下がる！

パスワード多すぎて覚えられないから付箋にメモしておこう

セキュリティリスク

---------------

---------------

---------------

ID 12345 PW abcde

♪

運用負荷

全アプリケーションのログ管理なんてできない！！



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

「社内アプリ」と「クラウドサービス」の両方を利用する構成で・ユーザの利便性向上・セキュリティ向上を実現するシングルサインオンが、将来目指すべき形。

SSO RP

セキュリティ強化は 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/パスワードを入力するのは、ドメインログオン時のみ。


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

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などのフェデレーション（認証連携）用のプロトコルを利用する方式。

利用者利用者情報なまえ利用者

メール [email protected]

電話 0x0-1234-5678

利用者情報

name themistruct

mail [email protected]

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

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


事例紹介


22

プロジェクトの概要

概要：サービス業様認証基盤構築プロジェクトバラバラの認証方式のアプリケーションに対して、代理認証方式によりシングルサインオンを実現

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

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

ポイント：社内ユーザーは統合Windows認証を利用可能とする。外部サーバー（勤務日確認システム）から取得した、アクセスしてきたユーザが勤務日かどうかの情報をもとに、アクセス判定を行う仕組みを実装する。


23

プロジェクトでの課題

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

「アプリの改修はできない！」「でもシングルサインオンは実現したい！」

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

実は…

リバースプロキシ型/代理認証方式は、やってみるまでできるかわからない。・リバースプロキシ型コンテンツ変換がうまくいかない（画面が正常に表示されない）場合がある。・代理認証方式アプリが複雑な認証方法をしている等、代理認証の実装に時間がかかるパターンが存在する。


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

SSOログイン用のID/パスワードとは異なるID/パスワードを使って代理認証を実現

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

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

24

構築のポイント

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

アプリケーション認証仕様の調査

代理認証を設定接続検証

を、アプリの数分実施


特殊な認可方法の実装

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

外部サーバにユーザ情報を問い合わせてアクセス制御を行うモジュールを新規に開発して対応。

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

• クライアント側のOS/ブラウザの組み合わせによっては、正常に動作しないバグが存在

OGISでバグ修正を実施

25

構築のポイント

OSSであるOpenAMだからこそ実現できた


認証基盤連携先システム

社外ユーザ

社内ユーザ

外部RPサーバ

内部RPサーバ

Active Directory

SSOサーバ

内部専用アプリケーション

外部公開アプリケーション DMZ

内部ネットワーク

インターネット

最終的なシステム構成

ThemiStruct-WAM

ID/パスワード認証

Windows統合認証

代理認証

代理認証

ユーザーがアクセス可能かどうかを問い合わせる

勤務日確認システム


ThemiStruct のご紹介


ThemiStruct のご紹介

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

シングル

サインオン

ID

配布・管理

サーバー

監視

ワンタイム

パスワード

電子証明書

配布・管理

ワーク

フロー

ThemiStructは企業の様々なシステムの“連携”を実現する６つのIT基盤ソリューションから成っています。企業を取り巻く様々なIT環境の変化と要求にお応えできるよう、日々進化し続けています。

社内とクラウドをシームレスにつなぐシングルサインオン

電子証明書の「発行」と「管理」をシンプルに実現


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

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

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

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

ThemiStruct-WAMだからこそ

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

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

• OpenAMはもちろん、ThemiStruct-WAM独自の部分全てにおいてサポートサービスが充実している

29

ThemiStruct-WAMの特徴


おわりに

30

シングルサインオンの目指す形は、「アプリで認証・認可をしない」

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

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

より最適な方法で、代理認証方式によるシングルサインオンを実現


おわりに

ご清聴ありがとうございました。

20141111 themi struct

Software