お客様事例

日東工業株式会社 様

「オンプレミスとクラウドが混在する環境」でのシングルサインオン認証基盤構築

カテゴリー: 事例  製造業

事例概要

Google、SFDCなどクラウドアプリケーションと、intra-mart、自社開発システムなどオンプレミスシステムへの、シングルサインオン認証基盤の構築

導入の経緯

業務システムの開発を依頼

n9-300x0.jpg

― 日東工業が、今回、GBSに依頼して構築したシステムの概要を教えてください。 日東工業では、社員1500名が活用するための、「社内アプリケーションへのシングルサインオン認証基盤」の構築を、GBSに依頼しました。 シングルサインオンの対象となったアプリケーションは4つ。
うち2つがオンプレミス、2つがクラウドです。各アプリケーションの詳細は次のとおりです。

n10-300x0.jpg

導入前の課題

システムの多様化に伴い、生じる課題

n2-150x0-250x0.jpg

― 今回、日東工業がシングルサインオン認証基盤を導入することに決めた理由、経緯を教えてください。

根本の部分からご説明いたします。

日東工業では、システムは基本的に社内開発しています。しかし最近は、「所有から利用へ」という考えを取り入れ、クラウドアプリケーションの活用も推進しています。

2012年には、従来のオンプレミスのグループウエアを、Google Appsに置き換えました。翌2013年には、Salesforce Chatterを使った、社内SNSの導入も進めています。

しかし、便利なシステムの導入には副作用もあります。管理者にとっての「ユーザーID管理工数の増大」、ユーザーにとっての「パスワード管理工数の増大」という問題です。

■ ユーザID管理、パスワード管理の工数増大という課題

― 「ユーザーID管理の問題」とは、具体的には。 ユーザー(従業員)が社内アプリケーションを使用するには、最初にユーザーID,パスワードを入力する必要があります。

ユーザーIDは、ユーザーの人事異動に合わせてアプリケーション管理者が管理します。パスワードは、ユーザーひとりひとりが自分で管理・変更します。 ユーザーIDやパスワードの変更や管理(記憶)の手間は、社内アプリケーションが一個であれば、大きな問題にはなりません。

しかし、現在の日東工業のように、複数のアプリケーションを使っている状況では、まずユーザーIDの管理の手間は、サーバ台数に比例して増加します。 パスワードについても、システムが増えると、ユーザーのパスワード記憶負担が増します。重要なシステムでは定期的なパスワードの変更を義務づけているので、負担はさらに増えます。

実際、社内からも、パスワード管理の手間を嘆く声が多く上がっていました。

「覚えられないから、みんな同じパスワードを使い回しているよ」 「ワークフローの承認申請がメールで来るけどメール内のURLをクリックしたら、『ID、パスワードを入力してください』という画面が…。どうにかならない?」 「裏でどんなシステムが動いているか気にしないといけないの?『朝1回、入力するだけ』で全部使えるようにしてほしい」 こうした不満を放置したまま、アプリケーションを増やし続けると、社内の不満はさらに増大するでしょう。便利さを追求するはずが、社内ユーザーの心が離れてしまうようでは本末転倒です。

この課題を解決するために、ID、パスワードを一度入力するだけですむ、「シングルサインオン」を導入したいと、かねてから考えていました。

日東工業では、今後もクラウドアプリケーションなど各種システムを導入して、社内情報システムの全体最適を実現させる方針です。今回は、シングルサインオン対象のアプリケーションは、セキュリティを考慮し、4つにとどめましたが、将来は、柔軟に対応したいと考えています。
その場合でも、シングルサインオン認証基盤を構築しておけば、ユーザーは、一つのID、パスワードで複数のアプリケーションにログインできます。アプリケー ションがいくつに増えても、パスワード管理の手間が増えることはありません。
部門内で協議の上、シングルサインオンのシステムを構築することを決定。その後は構築を依頼する、SI会社の選定を始めました。

選定の理由

SI会社を選定したときの「目のつけどころ」

― システム構築を依頼するSI会社を選定するにあたっての、「求めた要件(目のつけどころ)」を教えてください。

今回のシステム構築を依頼するSI企業への、「求めた要件」は、次のとおりです。

要件1. 「システム毎のロケーション、認証形式に対応が可能な、最適なシングルサインオンの実現」

当時の社内システム(情報系)は、intra-mart(オンプレミス)、Google Apps(クラウド)、FTWO(オンプレミス・自社開発システム)の3種類でした。システム構築を依頼するSI企業には、この「オンプレミスとクラウドが混在する環境」においても、適切にシングルサインオン認証基盤を構築できることを求めました。

要件2. 「アプリケーションとシングルサインオンの両方の知識、技術」

intra-martだけ、Googleだけ、あるいはシングルサインオンだけ詳しい会社なら、多くあります。しかし、今回のシステム構築を依頼するSI企業には、「intra-mart、Google、シングルサインオンの全ての特徴をよく理解していること」、さらには「Salesforce、Amazonなど主要クラウドアプリケーションについても十分な知識と技術があること」を求めました。

要件3.  「モバイル、iPad, BYODからの接続への対応」

今回のシングルサインオン認証基盤には、パソコン、iPadなど社内機器の他、BCP対策用の自宅PC、個人利用スマートフォン、iPadなど、いわゆる「BYOD機器」も接続します。接続元の機器の種別を問わず、確実な認証を可能にする基盤を構築することを求めました。

要件4. 「日東工業の『目指す業務のあり方』への十分な理解」

単にシステムを組むというだけでなく、私たちの「やりたいこと」、「目指す業務の姿」をよく理解し、それに沿った提案をしていただくことを求めました。

 

要件5. 「実績、信頼性、継続性」

今回、構築するシングルサインオンは、今後、「基盤」として長期にわたり活用します。その基盤の構築を依頼する会社には、十分な実績、信頼性、継続性が備わっていることが必要です。

要件6. 「競争力のある価格」

システム構築費用は、これら要件1~5を満たした上で、かつ費用と効果のバランスが良い価格であることを求めました。 これらの要件(目のつけどころ)を想定した上で、はじめは従来から取引のある大手企業2社に提案を求めました。 しかし、どちらも「納得のいく提案」には到りませんでした。

■ 日東工業がSI企業からの提案に望むこと― 最初の2社の提案は、どの点が納得できなかったのでしょうか。

n8-250x0.jpg

ひとつには、「 日東工業の『目指す業務のあり方』への理解」について違和感を感じたことです。 その提案は、「私たちの『目指すあり方』を実現するためのソリューション(解決策)」というよりは、「自分たちの取り扱い製品を売るための紹介」に重きが置かれている印象でした。

そこで「対象サーバに最適なシングルサインオン基盤について提案してほしい。またシングルサインオン技術の最新動向も知らせてほしい」と求めると、まず「シングルサインオン自体の解説」が始まり、結論は、「どんな仕組みにするかは御社次第」という回答でした。

日東工業では、将来を見据えたある程度のシステム全体像を想定していました。求めていたのは、その考え方と最新の動向とをすり合わせた最適な提案だったので、この結論には違和感を感じました。

私たちとしては、「自社に精通している情報システム部と、世の中の流れに詳しいSI企業が、『何を、何のために、いつ、誰が、どうやって実現するのか?』について同じ立ち位置で議論するからこそ、相乗効果が出るのだ」と考えています。 「良きパートナーを探す必要がある」 そんな思いを感じていたある日、偶然、GBSのことを知りました。

■ GBSを知ったときの印象

― GBSを知った経緯を教えてください。

東京で開かれていた展示会で、「何か面白いものはないか?」と思いながら、ブースを見回っていたときに、GBSを見つけました。 それまで、GBSという社名は知りませんでしたが、展示パネルに書いてあった、「intra-mart」「Gmail」「Salesforce」「シングルサインオン」というキーワードが気になったので、話を聞いてみることにしました。 2、3質問したところ、こちらの意図を引き出しつつ、明確な回答を返してくれました。実績もありそうです。ただ、それまでは知らない会社だったので、信頼性や継続性の点で懸念がありました。そこで、会社に戻ってから、GBSについて調査したところ「GBSは、JBグループのグループ企業であり、技術力もあり信頼性も高い。安心できそうな会社だ」という結論に至り、懸念は解消しました。 GBSの本格的な提案を聞いてみたいと思い、改めて問い合わせをし、その後、提案をいただき、精査しました。 その結果、「GBSは、技術、提案、継続性のいずれの点でも、日東工業が求める要件を良く満たしている」と判断し、2012年12月に、シングルサインオンのシ ステム構築の発注を決定。2012年12月に構築を開始し、2013年3月には、無事、システムを稼働させることができました。

GBSへの評価

GBSのシステム構築力への評価

n6-250x0.jpg

― 今回のシステム構築を通じてのGBSへの評価についてお聞かせください。

完成したシングルサインオン認証基盤は、大きなトラブルもなく、期待通りに稼働しています。社内からも「ログインが簡単になった」と好評です。 今回は、GBSには、きついスケジュールだったと思いますが、よくがんばっていただけました。心より感謝しております。 プロジェクトを通じて、「GBSの高いコミュニケーション力」には常に助けられました。具体的に述べると次の通りです。

キーワード1. 「顧客の課題解決を優先する姿勢」

GBSのみなさんとは、「クライアント・SI企業」、「買い手・売り手」ではなく、「共に課題を解決する、『仲間』」として、同じ目線で、「それはこうしたらいいのではないか?」、「いや、こうした方がいいかも」というように、活発な議論ができました。GBSは、全体構想を踏まえた「顧客の課題解決」を優先してくれるので、私たちも、安心して「課題解決のための会話」ができるのです。

キーワード2. 「どんな質問にも答えてくれる」

GBSには、「シングルサインオンサーバとアプリケーションサーバの認証の仕組み」、「オープンSSOと商用SSOの違い」、、「クラウド環境の認証の仕組み」、「社内外のシステムが混在した環境でのセキュリティーの担保」などについて、様々な質問を投げかけましたが、どんな質問にも納得できる回答がありました。担当の方が分からない場合でも、次回の打ち合わせには知識が豊富な専門術者を連れてきていただけるなど、こちらの質問には、常に真摯にご対応いただけました。

キーワード3. 「会話する中で『情報』が得られる」

今回、GBSとシングルサインオンについて議論していく中で、「GoogleやSalesforceなどクラウドアプリケーションの使いこなしノウハウ」、「ライセンスの賢い買い方」など、会話をするたびに発見がありました。

キーワード4. 「根底に『誠実さ』がある」

GBSとは、いつも「同じ目線」で話せますが、それが「なれあい」に陥ることはありませんでした。GBSのみなさんの、仕事に向かう姿勢の根底に、「誠実さ」があ るからだと思います。

このような「顧客の目的を理解し追求する、優れた提案力、そしてコミュニケーション力」を持つSI企業は、近年減っている印象があります。しかし、GBSは違う。日東工業 情報システム部門は、GBSの実力を高く評価しています。

■ 今後の期待

― GBSへの今後の期待をお聞かせください。

今回、GBSの尽力により、納得のいくシングルサインオン認証基盤が完成しました。GBSには、高い技術と手厚いサポートを通じて、私たちの取り組みを引き続きご支援いただきたいと思っています。今後ともよろしくお願いします。

参考情報:

GBS技術スタッフよりひとこと
~ 今回のシステム構築をふりかえって ~

以下、参考情報として、GBSの技術者より、「今回のシステム構築で技術的に難しかった点(苦労した点)」、「シングルサインオンで一般的に困難になる点」につきお知らせします。

◆ 今回の案件での設計上、実装上の困難(苦労した点)

・利用端末、利用形態についての要件が幅広く、すべての要件を IceWallで 漏れなく吸収するための設計が難しかった。
・IceWall と Samba のユーザーを LDAPに集約し、統合ID管理の実現を目指した。 このとき、ID情報を集約しつつ、IceWall、Sambaそれぞれの認証に影響を及ぼさない構成とするため、担当者間で何度も議論を重ねて実現した。
・Samba ファイルサーバ の ユーザーパスワード と IceWall ユーザーのパスワードを 同期したい、という要件があった。そのため、パスワード同期スクリプトを開発し、IceWallに追加導入することで対応した。
・Google Appsへの自動認証を実施するにあたり、他社が提供するサービスがフロントにいたため、他者が提供する自動ログイン APIに対応した リクエストを送信する必要があった。 そのため、自動ログイン用スクリプトを開発し、IceWall に追加導入することで対応した。
・IceWall に ID情報を集約するにあたり、ユーザー管理機能の開発を行った。 その際、お客様のご要望に応じたアプリケーションを開発するため、 ヒアリング~改修~テストのサイクルを重ねることで完成させることができた。
・IceWall の画面遷移(ログイン時、ログアウト時)について、製品標準外の 遷移方式としたい旨のご要望があった。 これに対応するため、独自画面の作成・JavaScriptの実装などにより対応した。

 

「シングルサインオンで一般的に困難になる点」

・SSOを実現するにあたり、アプリケーションに実装されている既存の認証機能 に対して自動的にログインさせるための設定(代理認証)を実施する必要がある。
・リバースプロキシ型のSSOを導入する場合、SSO対象アプリケーションサーバ に手を加えなくてよいメリットがある。 その反面、アクセスURLが変わるため、アプリケーションから返されるコンテンツ内 のURLを、すべてSSO経由のURLに変換する設定が必要となる。
・リバースプロキシ型のSSOを導入する場合、クライアントからのアクセスが すべてSSOサーバを経由することになる。 そのため、クライアント~SSOサーバへのアクセス経路を確保するとともに、 アクセス制御の要件をすべてSSO側で吸収するよう設計・設定を実施しなければならない。
・SSOを導入することにより、それまで気付かなかったアプリケーションの不具合が 顕在化する場合がある。 (RFC違反のHTTPレスポンスを、ブラウザが無視してくれるようなケース)

お客様プロフィール

お客様名
日東工業株式会社
所在地
〒480-1189 愛知県長久手市蟹原2201番地
URL
http://www.nito.co.jp/index.html
事業内容

日東工業は、配電盤やキャビネット、ブレーカ、サーバ用システムラックなど電気機械機具を製造、販売する企業です。近年は電気自動車向け充電スタンド や太陽光発電に関連する製品に注力しています。国内8工場、40営業所。中国とタイにも拠点。設立は昭和23年、売上高は680億円、従業員数は 1,600 名です。