2018年11月20日火曜日

新しいGoogleサイトでなくなった機能をなんとかしたい

新しい Google サイトが公開されてからずいぶん経過しましたが、使用感はいかがでしょうか。正直、以前の Google サイトではできていたのに、新しい Google サイトでは実現できないというものが多くあると思います。
例えば、お知らせやファイルキャビネットが使えなくなったり、各種ガジェットが使えなくなったり・・・
そこで、今回は新しい Google サイトになってなくなってしまった機能を弊社でご用意している Gluegent Gadgets で実現する方法をご紹介します。

新しいGoogleサイトでは何が使えなくなったのか

以前の Google サイトと新しいGoogleサイトの比較表が Google から公開されています。
以前の Google サイトと新しい Google サイトの比較

「デザインと編成」の「テンプレート:サイト用に事前にデザインされたテンプレートを使用する」とはページ作成時に選択する「テンプレート」のことです。
テンプレートには「ウェブページ」「お知らせ」「ファイルキャビネット」「リスト」「スタートページ」が用意されていました。
弊社でご案内したことがあるお客様でもよく使われるのが「お知らせ」と「ファイルキャビネット」です。
全社ポータルのトップページには「お知らせ」の最新の投稿記事が一覧できるガジェットを置き、社員へのアナウンスを掲載するといった使い方をよくされています。
また、就業規則やドキュメント類をファイルキャビネットに置いておき、社員に共有するということをされています。
新しい Google サイトに変えたいけど、これらの機能がなくなるのは困るので、新しい Google サイトに移行できないとお悩みではないでしょうか。
ではこれから、Gluegent Gadgets で代用してみましょう。

「お知らせ」には「掲示板ガジェット」

お知らせを新しい Google ガジェットに移行するとなんとただのウェブページに変換されてしまいます。各記事は下の階層に配置されます。もちろん、投稿はできなくなります。
代わりに、掲示板ガジェットをお使いください。
上記の比較表の「ページレベルの権限」も使えなくなってしまっていますが、掲示板ガジェットは各掲示板の管理権限・投稿権限・閲覧権限がユーザー・グループ単位で設定できます。
掲示板ガジェットでは見せるべき投稿を見せるべき人に公開するということができます。

「ファイルキャビネット」には「ドライブガジェット」

新しい Google サイトではファイルキャビネットの代わりとして挿入>ドライブを使うよう案内されています。しかし、指定のフォルダのファイルをリスト状に表示しているだけです。
これだけでも十分ですが、せっかくなら検索やツリー表示ができたら嬉しいですよね。


以上、今回は一部の機能だけですが、新しい Google サイトでなくなってしまった機能を代用する Gluegent Gadgets をご紹介しました。弊社では Gluegent Gadgets をもっと利用していただくため、無償提供キャンペーンを行っております。この機会に是非ご利用をご検討ください。



2018年11月13日火曜日

今日から始めるクラウド型ワークフローGluegent Flow(マスタデータ定義)

Gluegent FlowはG Suite (旧Google Apps)やOffice 365と連携することができるクラウド型ワークフローです。
本記事では前回の記事に続いて、G Suiteをご利用している中小規模の情報システム担当者の方を対象に、
Gluegent Flowを利用するにあたって必要となる導入・準備作業について、ワークフローで利用するマスタデータ参照機能の設定をGoogle スプレッドシートを利用し、どのように行っていくか、ご説明していきます。

Gluegent Flow導入時の準備作業

Gluegent Flowをご利用いただく際に必要となる導入時の作業内容は以下の通りです。
  1. Gluegent FlowをG Suiteにインストールする
  2. 組織階層をGoogleグループで定義する
  3. 初期設定を行う
  4. ワークフローをグルーピングするための「カテゴリ」を定義する
  5. 番号の採番ルール「シーケンス」を定義する
  6. 承認時の上長を自動判別するための「ロール」を定義する
  7. マスタデータをGoogleスプレッドシートに定義する
本記事では、上記No.7の設定内容についてご説明します。

No.1〜6の内容に関しては前回までの記事をご覧ください

<前回までの記事>


マスタデータをワークフロー毎に設定した場合の課題と対処策

ワークフローが参照するマスタデータとは、申請時のフォームに配置する単一チェックやリストの参照元データのことを指します。マスタデータの例としては、業務に関する区分・種類や、自社が取り扱う商品、そして取引先情報などが挙げられます。
このようなマスタデータをワークフローで扱いたい場合、そのワークフローの申請モデルに必要なデータを設定する必要があります。
ここで、複数の申請モデルにマスタデータを設定した場合のメンテナンスとして、商品マスタに新商品が追加になったケースを考えてみましょう。通常、追加された新商品のレコードは設定済の申請モデル数だけ追加作業が発生します。また、人手で変更することになるため、確認作業も当然必要となります。修正対象の申請モデルが2~3個ならまだしも、10個以上になってくると修正作業の労力もかなり大変です。
もし、この商品マスタデータ定義が申請モデルの外部で定義でき、一括編集できるとメンテナンス作業も1回で済み、作業労力も大幅に低下させることが可能となるでしょう。これを実現するのが、Googleスプレッドシートを利用したマスタデータ定義なのです。
スプレッドシートにマスタ定義することで、データ変更対象はそのスプレッドシートに限定させることができます。また、そのシートを申請モデル側から参照させるようにすることで、データ変更が発生しても申請モデルの修正は必要ありません。
更に、通常であればマスタデータ等は基幹システムで管理しており、そのシステムで追加・変更等の作業を行った後、ワークフロー側でも利用したいこともあるかと思います。この場合、変更があった商品マスタデータを自動でスプレッドシートに反映できるような仕組みを用意しておけば、人手を介することなく、ワークフローにて自動参照ができるようになります。
※弊社では他システム上のデータをGluegent Flowで利用可能とするため、CSV・スプレッドシート同期ツールを有償オプションとしてご提供しております。ご興味のある方はお問い合わせください。

マスタデータをGoogleスプレッドシートに定義し、申請モデルから参照する方法

それでは、Gluegent Flowでマスタデータをスプレッドシートに定義していく方法について説明していきましょう。
マスタデータとしてスプレッドシート参照が可能なフォーム項目は以下の通りです。
  • リスト
  • テキストとリスト
  • 単一チェック
  • 複数チェック
  • 親子リスト(★)
  • 親子テキスト(★)
  • 親子リスト(他項目連携)(★)
    (★):ヘッダー行が必要となるフォーム項目
親子リスト系の項目は選択肢の依存関係が定義できるものです。例えば、都道府県を定義した場合、関東地方を選ぶと、東京都、神奈川県、千葉県、埼玉県、群馬県、栃木県、茨城県が絞り込まれて表示できるようなものです。

それでは、以下からスプレッドシートへのデータ定義方法について説明していきます。
まずリストや単一チェックといった親子リスト系以外のフォーム項目が参照するデータの場合、以下のようにスプレッドシートへデータのみ定義します。ヘッダー行は必要ありません。


一方、親子リスト系のフォーム項目は、ヘッダー行とデータの両方を定義します。

スプレッドシートの準備ができたら、申請モデルから参照できるように設定してみましょう。
管理者権限を持つユーザでGluegent Flowアクセス後、右上のギアマークメニュー>設定を選択します。管理画面が表示されたら、モデル一覧>新規作成ボタンを押します。
申請モデル編集画面が表示されたら、「入力フォーム」を選択後、新規フォーム項目を追加し、以下の設定を行います。
  1. タイプを選択し(①)、フォーム名を入力します(②)
  2. 選択肢設定で「スプレッドシートを定義」を選択(③)、未設定リンクをクリックし、参照先となるスプレッドシートを指定します(④)。


編集途中、プレビューボタンを押すことでどのように表示されるか確認できます。
以下にスプレッドシートが参照可能なフォーム項目の初期表示および選択時のイメージを掲載しています。まず、初期表示時は以下のようになります。
各リスト選択後、以下のような表示となります。親子リスト系の場合、種類>商品名の依存関係に従って絞り込み表示されていることが確認できると思います。
※上記例では親子リスト系のヘッダー行タイトルが表示されていますが、テンプレートのプレースホルダー表記を${親子リスト.1}のようにすれば表示させないことも可能です。詳しくはマニュアルをご確認ください。

上記のような申請モデルの設定をしておけば、分類や商品が追加となった場合、スプレッドシート編集のみで申請モデルを再編集することなく、対応可能です。
なお、追加・変更されたマスタデータは新規申請分から反映されます。承認途中のものは、申請時点のマスタデータが表示するため、変更分は反映されません。


以上、Gluegent Flowのスプレッドシートによるマスタデータ定義を中心にご紹介しました。マスタデータをスプレッドシートに定義することでデータ管理の一元化およびメンテナンス作業の効率化が実現できることがお分かりいただけたと思います。
さて、全4回を通じてGluegent Flowの初期導入時に必要となる設定作業をご説明させていただきましたがいかがでしたでしょうか。本記事に関してご不明な点がございましたら、お問い合わせフォームからお問い合わせください。



2018年11月12日月曜日

【長期ご利用事例を紹介しています】10月のまとめ

10月のGluegentシリーズのリリースや、各種情報のまとめです。



『新しい Google サイト活用キャンペーン』の募集準備中です

新しい Google サイトに対応した、Gluegent Gadgetsの一部機能を無償提供するキャンペーンの募集準備をしています。11月中に募集開始予定です。もう少々お待ち下さい。
『新しい Google サイト活用キャンペーン』予告 〜 新しい Google サイトに対応した Gluegent Gadgets を無償提供 〜

Gluegent Gateの仕様を一部変更しました

パスワード期限警告に関する仕様を一部変更しました。
AD/LDAP認証の「パスワード同期」の仕様を一部変更しました。
Gluegent Gate リリースのお知らせ(2018/10/11)

株式会社 熊谷組様 の事例をご紹介しています

弊社製品を広く長期間ご利用頂いています。
https://www.gluegent.com/customer/2018_kumagaigumi/

 Gluegent Gate

2018年11月6日火曜日

IDaaSとは、何か? (6) 〜利便性とセキュリティの両立〜

IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の第6回目です。前回までで、IDaaSが持つ機能を個別の機能として捉えて、それぞれについて掘り下げてきました。一回目の記事、[IDaaSとは、何か(1)」で示した以下の機能群です。

  • 保存:Identityに関する情報を保存・管理する。
  • 認証:利用者が誰なのかを管理する。
  • 認可:利用者が許可されているサービスやリソースを管理する。
  • プロビジョニング: 利用者が許可されているサービスに対して、アカウントを管理する。

前回は、IDaaSとは、何か? (5) 〜使えるように準備する〜として、「プロビジョニング」について、見てみました。今回は、「シングルサインオン」です。


シングルサインオンってなに?

シングルサインオン(SSO)とは、「一度ログインするだけで、本来それぞれログインしなければならない複数のサービスに対し、ログインした状態になる」ということです。IDaaSの文脈で言えば、IDaaSが提供するログイン画面からログインすると、IDaaSと連携するすべてのサービスで、個別のログイン画面でログインすることなしに、サービスを利用できるということになります。
単純に考えると、「ログインIDとパスワードを入れる回数が減って楽になる」というだけのように思えますが、他にも様々なメリットがあります。ログインが一箇所だけで良いというのは、どういう意味なのでしょうか。

認証情報が一つでよい

ログインするためには、IDaaSとは、何か? (3) 〜訪問者は誰?〜で見たように、ID/パスワードに代表される、「認証情報」が必要です。その人が誰であるかを示すものと、その人しか知り得ない情報をもって、システムに対して、ログインしようとしている人が誰かを示す必要があります。
シングルサインオンを使っていない場合、複数のシステムがあると、それぞれで固有の「認証情報」が必要です。あるサービスでは、IDにメールアドレスを使うことになっているのに、別なサービスでは、システムから配布される数値をIDとしているというように、ルールが異なることがあります。また、サービス毎にパスワードポリシーが異なったり、定期的な変更が求められたり、パスワードの管理も大変です。
シングルサインオンが導入されると、これらの煩雑な認証情報の管理が一つだけで良くなります。では、この認証情報の管理が一つで良いということは、どういう意味があるのか、さらに掘り下げてみましょう。ユーザと管理者の視点から見てみます。

ユーザにとっては、利便性の向上

ユーザにとっては、覚えることも少なくて済みますし、認証情報というクリティカルな情報の管理が一つだけで良いということは、それだけ本業に専念できるということになります。ログインするという動作についても、一回で済みます。利用するサービスが増えたとしても、同様です。
つまり、一つの認証情報の管理という最小の労力をもって、有用な複数のサービスを利用できるという「利便性」が提供されるということになります。これまでは、情シスから、「新しいサービスを使うことになったので、このIDを使ってください。パスワードはしっかり管理してくださいね。」と言われていたのに、シングルサインオンを導入されると、「新しいサービスを入れましたが、いつもの認証情報でログインしてもらえれば、使えます。」というように変わります。
シングルサインの導入は、ユーザにとって大きなメリットと言えそうです。

管理者にとっては、セキュリティの強化

管理者にとっては、どうでしょうか。シングルサインオンが導入されていない場合、ユーザに、サービス毎にIDを配ったり、登録してもらったりしていたと思います。あるいは、IDaaSとは、何か? (5) 〜使えるように準備する〜でみたような「プロビジョニング」の機能がなんらかのシステムで提供されている場合は、アカウントの登録は自動的に行われるかもしれません。ただ、「認証情報」に含まれる、パスワードに代表される「その人しか知り得ない情報」は、ユーザ本人のものです。管理者も知ることはできませんし、「管理者によるなりすまし」を防ぐためには、管理者は知るべきではありません。
そのため、シングルサインオンが導入されていない場合、多くの有用なサービスを導入したとしても、「認証情報はユーザの責任で管理すること」として、サービスの数だけクリティカルな情報をユーザに管理させることになります。本業が忙しいユーザは、クリティカルな情報だとしても、管理が杜撰になり勝ちです。複数サービスでパスワードを使いまわしたり、予想可能なものにしたり、総当りを許しそうな短いものにしたり、セキュリティリスクになり得る管理方法がとられます。そのため、管理者としては、長さを指定したり、定期的な変更を強制したりしますが、効果は薄いと言えるでしょう。(参考:パスワードの定期的な変更が不要とされたことの意味とは?)
有用なサービスを多く提供したとしても、ユーザに対して、高いセキュリティを維持する責任の一旦を担わせているということになります。高いセキュリティを維持することは、ユーザの責任というようりも、情報システム管理者の責任と言えるでしょう。ユーザには本業を頑張ってもらうべきです。
シングルサインオンは、このような状況を解決することができます。シングルサインオンを提供する基盤を採用し、シングルサインオンに対応するサービスを導入することで、ユーザに過大な責任を追わせずに、高いセキュリティを維持したまま、有用なサービスを提供することができます。

次回はまとめです

今回までで、6回にわたって、IDaaSの機能について見てきました。それぞれの機能は、これまでも単機能として提供されてきたものですが、IDaaSとして、一つのサービスにまとまり、有機的に組み合わされることで、クラウドサービス当たり前時代に、必須なサービスとなっています。次回は、全体のまとめとして、これらの機能が組み合わされることでどのような意味があるのか、掘り下げてみます。

   Gluegent Gate


2018年10月30日火曜日

新しいGoogleサイトで作った社内ポータルに共有アドレス帳・グループスケジューラを配置してみよう

Gluegent Apps共有アドレス帳はG Suite(旧Google Apps)やMicrosoft Office 365を導入している企業に最適な全社で共有できるアドレス帳ツールです。
Gluegent AppsグループスケジューラはG SuiteのGoogleカレンダーをチームで活用するためのツールです。
よく、お客様から「共有アドレス帳やグループスケジューラを新しいGoogleサイトで配置したい」というお問い合わせをいただきます。せっかく社内ポータルをGoogleサイトで作って運用しているので、共有アドレス帳やグループスケジューラをユーザーに使わせたいとお思いの方も多いことでしょう。
そこで、今回は共有アドレス帳やグループスケジューラを新しいGoogleサイトの社内ポータルページに配置する方法をご説明します。

新しいGoogleサイトページに共有アドレス帳/グループスケジューラを貼り付ける方法

新しいGoogleサイトページにはHTMLを埋め込むための機能が備わっています。その機能を使えば外部サイトページを自社のページ内に表示できるようになります。
本記事では既に社内ポータルページを新しいGoogleサイトで作成しているものとし、下図のようにステータスガジェットを配置していくための手順を説明していきましょう。


まず編集対象となるGogoleサイトのページ編集画面を開き、右側のメニューにある埋め込みボタンを押します。

すると、ダイアログが表示されるので「埋め込みコード」を選択し、編集欄にコードを入力します。このコード欄には以下のHTMLコードを入力してください。入力後に「次へ」をクリックします。

埋め込みコード:
<iframe src="https://gluegent-addressbook.appspot.com/openid?hd=<ドメイン名>
&continue=https%3A%2F%2Fgluegent-addressbook.appspot.com%2Faddresslist.html
%3Fredirect%3Dhttps%3A%2F%2Fgluegent-addressbook.appspot.com%2Faddresslist.html" 
 width="100%" height="100%"></iframe>

<ドメイン名>の箇所は、お使いのG Suiteのドメイン名(例:example.com)を指定してください。

コード例:
<iframe src="https://gluegent-addressbook.appspot.com/openid?hd=example.com
&continue=https%3A%2F%2Fgluegent-addressbook.appspot.com%2Faddresslist.html
%3Fredirect%3Dhttps%3A%2F%2Fgluegent-addressbook.appspot.com%2Faddresslist.html" 
 width="100%" height="100%"></iframe>

 HTMLコード入力後、次へボタンを押すとプレビュー画面が表示されますので、保存ボタンを押します。

編集中のページにステータスガジェットが挿入できました。

確認ができたら、公開ボタンを押して現時点の編集内容で公開しましょう。

グループスケジューラの追加手順も同様です。埋め込みコードを以下のように設定してください。
埋め込みコード:
<iframe src="https://gluegent-scheduler.appspot.com/openid?hd=<ドメイン名>
&continue=https%3A%2F%2Fgluegent-scheduler.appspot.com%2Fconsole.html
%3Fredirect%3Dhttps%3A%2F%2Fgluegent-scheduler.appspot.com%2Fconsole.html" 
 width="100%" height="100%"></iframe>

<ドメイン名>の箇所は、お使いのG Suiteのドメイン名(例:example.com)を指定してください。

コード例:
<iframe src="https://gluegent-scheduler.appspot.com/openid?hd=example.com
&continue=https%3A%2F%2Fgluegent-scheduler.appspot.com%2Fconsole.html
%3Fredirect%3Dhttps%3A%2F%2Fgluegent-scheduler.appspot.com%2Fconsole.html" 
 width="100%" height="100%"></iframe>


以上、共有アドレス帳とグループスケジューラを新しいGoogleサイトのページに埋め込む方法をご紹介しました。非常にシンプルな操作で表示できるようになったと思います。このように新しいGoogleサイトではiframeによるページ埋め込みが簡単に行えるようになっております。ぜひお試しください。



2018年10月23日火曜日

今日から始めるクラウド型ワークフローGluegent Flow(ロール)

Gluegent FlowはG Suite (旧Google Apps)やOffice 365と連携することができるクラウド型ワークフローです。
本記事では前回の記事に続いて、G Suiteをご利用している中小規模の情報システム担当者の方を対象に、
Gluegent Flowを利用するにあたって必要となる導入・準備作業について、ワークフローに対するロール機能の設定をどのように行っていくか、ご説明していきます。

Gluegent Flow導入時の準備作業

Gluegent Flowをご利用いただく際に必要となる導入時の作業内容は以下の通りです。
  1. Gluegent FlowをG Suiteにインストールする
  2. 組織階層をGoogleグループで定義する
  3. 初期設定を行う
  4. ワークフローをグルーピングするための「カテゴリ」を定義する
  5. 番号の採番ルール「シーケンス」を定義する
  6. 承認時の上長を自動判別するための「ロール」を定義する
  7. マスタデータをスプレッドシートに定義する
本記事では、上記No.6の設定内容についてご説明します。
No.1〜5の内容に関しては前回までの記事をご覧ください

<前回までの記事>


部署毎の承認者を自動判別するロール機能が必要な理由

ワークフロー定義(申請モデル定義)では、入力フォームに加え、承認経路も重要な要素です。例えば、下図の組織において申請モデル「稟議申請」の承認経路で役職:課長が処理者として設定する場合を考えてみます。

営業部には営業一課および二課が存在し、それぞれの課にはAさん、Cさんが課長だったとします。営業一課所属のBさんが稟議書を申請し、課長承認を依頼する場合、営業一課課長であるAさんが承認先となります。一方、営業二課所属のDさんの場合は、Cさんが承認先となります。つまり、申請者が所属する部署毎の役職者に承認依頼をすることになります。
ここで、もし承認者を個人でしか設定できないとどうなるでしょうか。その場合は課の数だけ同じ内容の申請モデルを用意することになります。しかし、それはメンテナンスの観点から現実的ではありません。そのため、申請モデルは1つだけ定義し、承認者の設置絵は申請者自らが指定する運用が考えられます。しかし、その場合、申請者がわざわざ上長を各承認者として選ぶため、申請時に余計な手間が掛かるようになります。
この課題を解決する機能が「ロール機能」です。次からこのロール機能に必要なロール定義について説明していきます。

ワークフローで承認者・決裁者を自動判別するための「ロール」を定義する

Gluegent Flowでは「ロール」という機能を使って部署毎の役職者を自動判別することができますが、そのためには部署・役職者に関するマスタデータをGluegent Flowに設定しておく必要があります。
ロール管理を表示する手順は、Gluegent Flowのギアメニュー>設定を選択し、モデル管理メニュー>ロール管理を選択します。
ロールを新規に作りたい場合は、新規作成ボタンを押します。

編集用ダイアログが表示されたら、ロール名(①)、そのロールの割当先組織グループ名(②)、そのロール対象となるユーザ名(③)を指定し、OKボタン(④)を押します。
登録が完了すると一覧に表示します。
上記の手順でロールの数だけ定義していきますが、G Suite版の場合、スプレッドシートにロール定義を記述しておき、それを一括でインポートすることでより効率的にメンテナンスすることが可能です。以下からスプレッドシートによるロール定義方法を説明していきます。
まず、Googleスプレッドシートにロール定義を用意します。
スプレッドシートの先頭行に「groupId」「managerId」「role」を記述します。2行目から以下の内容を設定していきます。
  • groupId
    • ロールの割当先組織グループID
  • managerId
    • ロール対象ユーザID
  • role
    • ロール名

<スプレッドシートの設定例>

次にGluegent Flowで上記スプレッドシートの定義内容を取り込みます。Gluegent Flowの設定>ロール管理画面にある新規作成ボタン横のプルダウンをクリックし、表示されたメニューから「インポート」を選択します。
同期対象シートを選択する画面が表示されますので、上記シートを指定後(①)、同期ボタン(②)を押します。
確認ダイアログが表示されるので、OKボタンを押します。
取込処理が完了するまでしばらく待ち、再表示すると取り込まれたロール一覧が確認できます。

申請モデル側のロール設定

前述までのロール設定を踏まえ、申請モデル側の経路設定でどのようにロールを設定するか説明していきます。
申請モデルのロール設定場所は、モデル編集画面>経路で対象の経路名(例:課長承認待ち)を選択し、設定欄のアコーディオンメニューから担当者設定を選択すると表示します。

ロール設定欄では2種類の選択肢がありますが、通常は「すべての階層のロールが対象」を選択してください。そして、ロールリスト(①)からその経路に指定したいロール名を「+」ボタン(②)で追加すると、割り当てられたロール名がロール一覧(③)に追加・表示します。

上記の設定を参考に経路「課長承認待ち」には「課長」ロールを、経路「部長承認待ち」には「部長」ロールを設定した申請モデルで新規申請を行った時の経路担当者の表示イメージは以下の通りです。


兼務している社員が申請する場合のロール判別は?

複数の組織に所属している兼務社員の場合のロール判別はどうなるか最後に説明しておきます。ロールは組織グループIDごとに設定したロールであるため、組織が確定すればその組織に紐づくロールは抽出できます。所属組織グループが1つとなる一般的な社員の場合は自動で設定できますが、兼務者の場合、新規申請時に右上に表示される所属組織グループを切り替えることで申請元の所属組織を切り替えることでロールも変わります。
以下では「営業一課」「営業二課」に所属している兼務社員が所属グループを切り替えることで「課長承認待ち」の処理担当者名が変わることがわかると思います。





以上、Gluegent Flowのロール機能の設定方法についてご紹介しました。申請モデル側でのロール設定に関する活用方法については後日ご紹介したいと思います。


2018年10月16日火曜日

IDaaSとは、何か? (5) 〜使えるように準備する〜

IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の一回目の記事、[IDaaSとは、何か(1)」で、以下の機能があるとご紹介しました。

  • 保存:Identityに関する情報を保存・管理する。
  • 認証:利用者が誰なのかを管理する。
  • 認可:利用者が許可されているサービスやリソースを管理する。
  • プロビジョニング: 利用者が許可されているサービスに対して、アカウントを管理する。

前回は、IDaaSとは、何か? (4) 〜どのサービスを使わせるか〜として、「認可」について、見てみました。今回は、「プロビジョニング」です。


プロビジョニングってなに?

プロビジョニング(provisioning)とは、広義では、サーバやサーバのリソース等を使えるようにするという意味ですが、IDaaSの文脈では、「対象サービスでアカウントを準備し、ユーザが利用できるようにする」といった意味合いです。
前回までの記事で見てきた通り、IDaaSでは、IDentityに関する情報を「保存」していて、その情報に基づいて、利用者が誰かを「認証」によって明らかにします。さらに、明らかになったユーザにどのサービスが許可されているかを「認可」によって、確認します。ただ、認可されているサービスがわかったとしても、そのサービスの方では、まだ利用可能な状態に準備されていません。ここで、「利用可能な状態に準備する」という処理がプロビジョニングです。IDaaSが持つ情報を使って、対象サービスにアカウントを作成し、利用できる状態にします。

プロビジョニングまで出来て一気通貫

プロビジョニングまで出来れば、なにもない状態から、利用者にサービスを利用させる準備が整うところまでの処理が一通り揃うということになります。例をあげてみましょう。
例えば、営業担当にGmailとSalesforceを利用させる会社に、社員が入社したとします。IDaaSが導入されていなければ、GmailとSalesforceの双方に、アカウントを個別に作成する必要があります。IDaaSを導入していて、Gmailと、Salesforceにプロビジョニング連携設定ができていれば、IDaaSで、アカウントを作成し、GmailとSalesforceを認可してあげることで、GmailとSalesforceにも、自動的にアカウントが作成され、利用可能な状態になります。その上、認証は、IDaaSがシングルサインオンでまとめるので、個別にログインする必要はありませんし、パスワードの管理も不要です。利用するサービスが複数ある場合でも、IDaaSに登録して、認可するだけで、入社準備が完了するということになります。

準備だけでなく、更新や、利用中止まで

プロビジョニングは、利用を準備するという処理だけに注目が集まり勝ちですが、運用していく上で重要なのは、情報の更新や、利用の中止についても、管理できるという点です。情報は、運用していく中で、更新されることもありますし、削除されることもあります。IDaaSが対象サービスに対して、プロビジョニングをサポートしている場合、IDaaSで情報を更新することで、認可されているサービスに情報が伝搬します。
先の例で言えば、営業担当者の姓が変わった場合、IDaaSで変更することで、Gmail、Salesforceの情報も更新されます。さらに、異動により、営業部を離れるとすると、Salesforceは利用しなくなります。ただ、Gmailはそのまま利用します。そのようなケースでは、IDaaSで、Salesforceの利用する設定を外すことで、Salesforce側のアカウントは利用停止状態となります。
退職や、異動により、利用していたサービスを利用できない状態にするということは、利用開始時に比べて、軽視されやすいものですが、セキュリティの観点に立つと、非常に重要な意味を持ちます。

すべてを一箇所で

ここまで見てきたように、プロビジョニングがサポートされていると、IDaaS上の情報のみを適切に管理することで、連携するサービス上のアカウントを管理することができます。昨今のクラウドサービスは、高度な単機能を提供するものが多くあります。そのため、必要なサービスを必要に利用者だけに必要な期間だけ提供するという運用が求められます。そのような運用をするためには、個別のサービス上で、それぞれアカウントを管理するのは、現実的ではありません。利用可能にすることが出来ても、適切に利用できないようにするという処理を徹底するのは、難しいでしょう。退職者のアカウントを削除し忘れていて、利用できるようになっていたという状況は避けなくてはなりません。
そのような要件を満たすのが、プロビジョニング機能を備えたIDaaSです。一箇所だけ注意しておくことで、迅速なサービス利用準備と高いセキュリティを実現できます。

シングルサインオン

今回掘り下げたプロビジョニングまでできることで、利用準備を整えられました。次回は準備できた環境を使うにあたって、高い利便性をユーザに提供すると同時に、高度なセキュリティも実現する、「シングルサインオン」について、掘り下げてみます。

   Gluegent Gate


2018年10月10日水曜日

【新しいGoogleサイト活用キャンペーン予告】9月のまとめ

9月のGluegentシリーズのリリースや、各種情報のまとめです。



『新しい Google サイト活用キャンペーン』を提供予定です

新しい Google サイトに対応した、Gluegent Gadgetsの一部機能を無償提供するキャンペーンを予定しています。
『新しい Google サイト活用キャンペーン』予告 〜 新しい Google サイトに対応した Gluegent Gadgets を無償提供 〜

グループキャッシュ更新スケジュールの設定が可能になりました

Gluegent Flowの「グループキャッシュ」の更新スケジュールをお客様の管理画面から設定することができるようになりました。
Gluegent Flow リリースのお知らせ(2018/09/20)

Gluegent Gate のパスワードポリシーで使用文字種数を設定できるようになりました


より柔軟なパスワードポリシーの設定が可能です。
Gluegent Gate リリースのお知らせ(2018/09/06)

 Gluegent Gate

2018年10月9日火曜日

色々なクラウドサービスとシングルサインオン(SSO)を設定してみよう - Office 365編 -(2018年版)

弊社が提供するGluegent Gateは、シングルサインオン・ID管理・アクセス制御の機能を兼ね備えたクラウドサービスです。現在、多くのサービスが、SAML 2.0という認証連携の標準規格に対応しておりますが、Gluegent GateではこのSAML 2.0という規格を利用して様々なクラウドサービス(G Suite(旧Google Apps)、Office 365、Salesforce、Dropbox、Box、サイボウズ等)とのシングルサインオンを実現しています。認証をGluegent Gateに集約し、そこでアクセス制御を行うことにより、各種クラウドサービスを横断的にセキュリティ強化することが可能となります。

さて、今日はOffice 365とシングルサインオンを行うための設定手順について取り上げたいと思います。

※この記事は2017年6月に公開した記事の画像を最新版にしたものです。

前提条件

まず、Gluegent GateがOffice 365とシングルサインオンできるようにするためには、以下の作業が完了している必要があります。

    <Office 365とシングルサインオン連携するための前提条件>
  1. Office 365に連携するドメイン名(xxx.onmicrosoft.com以外)が登録済であること
  2. Gluegent Gateにユーザ/グループが登録済であること
  3. Gluegent Gateに認証/認可ルールが定義済であること

No.1が特に重要です。Office 365と連携するためにはxxx.onmicrosoft.com以外のドメインをOffice 365のドメインとして登録しておくことが必要です。またxxx.onmicrosoft.comは「既定」として設定しておきます。

 Office 365管理センターのドメイン設定画面設定例


シングルサインオン設定手順の流れ

Office 365とのシングルサインオンを行うための設定手順は以下の通りです。G Suiteと違い、IdP証明書登録作業は必要ありません。

    <シングルサインオン設定手順>
  1. Gluegent GateのSSO設定画面で各種設定項目を入力する
  2. Gluegent Gateのユーザ設定画面でOffice 365に関する設定を行う
以下に詳しく説明していきます。

手順1. Gluegent GateのSSO設定画面で各種設定項目を入力する

Gluegent Gateへログイン後、以下の作業を行います。

  1. 画面左側メニューの「シングルサインオン」をクリックします。
  2. 「クラウドサービス」をクリックします。
  3. 「Office 365」をクリックします。
  4. 設定項目を入力します。
    • 設定画面ではメールボックスに関する設定もできますが、本稿ではシングルサインオンに必要な設定のみ行っています
  5. 保存ボタンをクリックします。
設定項目の説明
No.
設定項目
設定内容
1
シングルサインオンの設定
「有効」にチェック
2
Office 365ドメイン (必須)
Office 365と連携するドメイン名を入力
(xxx.onmicrosoft.com以外)
3
ID同期 
「有効」にチェック
4
Office 365管理アカウント名 (必須) 
Office 365の管理権限を持つxxx.onmicrosoft.comドメインのユーザを入力
5
管理者アカウントのパスワード
上記No.4で設定した管理者アカウントのパスワードを入力
6
ユーザ名の属性
Office 365との連携にGluegent Gateユーザ情報のメールアドレスまたはユーザIDのどちらを利用するか指定
7
シングルサインオンの方式
「SAML」「WS-Federation」のどちらかを指定
(通常は「WS-Federation」を指定)

上記設定の中で、No.2, No.4は間違いやすいところなので気をつけましょう。

手順2. Gluegent Gateのユーザ設定画面でOffice 365に関する設定を行う
Office 365と連携するためのユーザを指定します。
  1. 画面左側メニューの「ユーザ」をクリックします。
  2. ユーザ一覧からOffice 365と連携したいユーザを選択します。
  3. 以下の設定を行います。
    • メールアドレス
      • Office 365で登録したドメイン名を持つユーザのメールアドレスを入力
    • 許可するサービス
      • 「Office 365」にチェックを付与
    • Office 365のロール
      • Office 365側のライセンスを指定
      • ※この設定欄が表示されるまでSSO設定後最大45分間かかる場合があります
  4. 保存ボタンをクリックします。
  5. 連携したいユーザについて上記No.2〜4を繰り返します


設定後の確認

設定が一通り完了したら、動作確認を行ってみます。

  1. Webブラウザのプライベートモードによるウィンドウを表示し、ロケーションバーに「https://portal.office.com」を入力し、アクセスします。
  2. Office 365の認証画面でGluegent Gateで連携ユーザとして設定したユーザのメールアドレスをユーザIDに入力し「次へ」をクリックします。
  3. するとログイン画面にリダイレクトされますので、Gluegent Gateで登録したユーザID/パスワードを入力後、ログインします。
  4. ログイン後、Office 365が表示できたら成功です。


いかがだったでしょうか。上記のような設定でOffice 365とのシングルサインオンがGluegent Gateで簡単に実現できることがお分かりいただけたかと思います。次回も他サービスとのSSOに関する設定方法についてご紹介していきますのでお楽しみに。

 Gluegent Gate