2018年12月11日火曜日

豊富なテンプレートを使って業務フローを秒速で作ろう

「社内稟議」に「休日出勤」に「休暇」に「出張」に・・・業務で使っている「申請書」「ワークフロー」は様々あると思います。業務フローをクラウド化するとき、今使っている業務フローをすべて電子化するのは大変そうに感じるのではないでしょうか。
実は、Gluegent Flowではすぐに使えるテンプレートをたくさん用意しています。今回はGluegent Flowのテンプレートを使って業務フローを作成する方法をご紹介しましょう。

テンプレートを使うメリット

ワークフローシステムを導入したり、他社から乗り換えたりした時に一番大変なのは申請書を作ることです。今使っているものをワークフローシステムに作る、今のシステムで作ったものを新しいシステムでもう一度作成する、こういった労力は結構大変です。
しかし、先程挙げた「社内稟議」「休日出勤」「休暇」「出張」などの申請書はレイアウトの差こそあれ入力項目の内容は殆ど同じです。
Gluegent Flowではこの労力を軽減するために様々なテンプレートをご用意しています。

テンプレートを使ったモデル(申請書)の作成方法

それでは、実際にGluegent Flowの画面を使ってテンプレートからモデルを作成する方法をご紹介します。

Gluegent Flowの画面右上のギアアイコンをクリックし「設定」をクリックします。

画面左側のメニューから「モデル管理」の「テンプレート一覧」をクリックします。

テンプレート一覧が表示されます。作成したいテンプレートを選びましょう。
画面右側のアイコンでプレビュー表示ができますので、作成したいテンプレートイメージを確認しましょう。

このテンプレートでよければ、コピーします。「×」または「閉じる」をクリックし、一覧に戻り、画面右側のコピーアイコンをクリックします。

テンプレートから作成されたモデルは「カテゴリ未設定」で「非公開」の状態で作成されます。

モデル名をクリックして編集画面に遷移します。
経路・入力フォーム・入力チェックをクリックして、細かい調整を行ったあとは、「モデルを公開する」を選択して「保存」をクリックします。

テンプレートから作ったモデルで申請をする
作成されたモデルを使って申請をしてみましょう。


いかがでしたでしょうか。テンプレートを使うことで、簡単に複数のモデルを作成することができたのではないでしょうか。Gluegent Flowではこのように簡単に申請書を作成し、業務フローを円滑に進めるためのお手伝いができるかと思います。また、もっと複雑なモデルを作成することができます。この機会に是非ご利用をご検討ください。



2018年12月4日火曜日

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

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

さて、今日は最近利用者が増えてきているLINE WORKSとシングルサインオンを行うための設定手順について取り上げたいと思います。

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

LINE WORKSとのシングルサインオンを行うための設定手順は以下の通りです。G Suiteと違い、IdP証明書登録作業は必要ありません。
    <シングルサインオン設定手順>
  1. LINE WORKS Developer ConsoleでConsumer Key, Tokenを発行する
  2. Gluegent GateのSSO設定画面で各種設定項目を入力する
  3. Gluegent Gateのユーザ設定画面でLINE WORKSに関する設定を行う
以下に詳しく説明していきます。

手順1. LINE WORKS Developer ConsoleでConsumer Key, Tokenを発行する

Gluegent GateがLINE WORKSと連携できる上で必要となるConsumer KeyやTokenをLINE WORKS側で用意します。
  1. LINE WORKS Developer Consoleへ管理者ユーザでログインします。
  2. ドメイン名(①)、Tenant ID(②)、Domain ID(③)、API ID(④)を確認・コピーしておきます。
  3. 「Server API Consumer Key」欄の発行ボタンを押します。
    1. サーバーAPIの利用範囲で「管理者画面」と「組織連携」にチェックを付け、次へボタンを押します。
    2. Tokenの有効期間を「365日」、Toke有効期間の自動延長を「はい」で選択し、保存ボタンを押します。
    3. 新たに発行されたConsumer Keyがリスト表示されるので、Key列のコピーボタンからConsumer Key(⑤)をコピーしておきます
  4. Server List(固定IPタイプ)欄の追加ボタンを押します。
    1. サーバー名、Keyの選択(手順3で追加したConsumer Key)およびIP(175.41.253.63)を指定し、発行ボタンを押します 。
    2. 確認ダイアログでOKボタンを押すとTokenを発行されるので、コピーボタンからコピーしておきます。


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

続いて、Gluegent Gate管理画面へログイン後、以下の作業を行います。
  1. 画面左側メニューの「シングルサインオン」をクリックします。
  2. 「クラウドサービス」をクリックします。
  3. 「LINE WORKS」をクリックします。
  4. 設定項目を入力します。
  5. 保存ボタンをクリックします。
 <Gluegent Gate 設定画面(※数字はLINE WORKS 側で取得した値)>
設定項目の説明
No.
設定項目
設定内容
1
シングルサインオン の設定
「有効」にチェック
2
ドメイン
LINE Works Developer Consoleで確認した「ドメイン」(①)を指定する。ドメインはLINE WORKSの契約ライセンスに応じて変わる。

  • ドメイン名(例:gluegent.com)
  • グループID(例:gluegent)
3
ID同期 
「有効」にチェック
4
Tenant ID
LINE Works Developer Consoleで確認した「Tenant ID」(②)を指定する
5
Domain ID
LINE Works Developer Consoleで確認した「Domain ID」(③)を指定する
6
API ID
LINE Works Developer Consoleで確認した「API ID」(④)を指定する
7
Consumer Key
LINE Works Developer Consoleで発行した「Consumer Key」(⑤)を指定する
8
Token
LINE Works Developer Consoleで発行した「Token」(⑥)を指定する


手順3. Gluegent Gateのユーザ設定画面で同期対象ユーザを追加する
手順1〜2までの設定が完了したら、LINE WORKSと連携するためのユーザを指定します。
  1. 画面左側メニューの「ユーザ」>「新規登録」をクリックします。
  2. 以下の設定を行います。
    • ユーザID
    • 氏名
    • メールアドレス
      • ユーザIDと、手順2の連携設定で指定したLINE WORKSのドメインまたはグループIDを指定
    • パスワード
    • 許可するサービス
      • 「LINE WORKS」にチェックを付与
  3. 保存ボタンをクリックします。
  4. 連携したいユーザについて上記No.2〜4を繰り返します

設定後の確認

設定が一通り完了したら、動作確認を行ってみます。
  1. Webブラウザのプライベートモードによるウィンドウを表示し、ロケーションバーに「https://talk.worksmobile.com」を入力し、アクセスします。
  2. LINE WORKSの認証画面でGluegent Gateで連携ユーザとして設定したユーザのメールアドレスをユーザIDに入力し「はじめる」をクリックします。

  3. するとログイン画面にリダイレクトされますので、Gluegent Gateで登録したユーザID/パスワードを入力後、ログインします
                  
  4. ログイン後、LINE WORKSのトーク画面が表示できたら成功です。



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



 Gluegent Gate


2018年11月27日火曜日

IDaaSとは、何か? (7) 〜その価値とは?〜

今回は、IDaaSについて紐解く人気シリーズ「IDaaSとは何か」の最終回です。各回で、IDaaSが持つ複数の機能を掘り下げてきました。今回は、それらがどのように協調して、IDaaSとしての価値を提供するのか、見てみたいと思います。
それぞれの記事の内容を振り返り、ストーリーがつながることを確認します。


IDの一元的な保存について考える

第二回で、「保存」について説明しました。「Identityに関する情報」が、一箇所に「保存」されていていることの重要性についてです。複数の場所に保存されているのではなく、一元管理されることで、常に新しく、正しい「Identity情報」の保存と、参照が可能であることを説明しました。
一箇所に保存されていない場合には、同期の必要があったり、同期するまでは、一方が古い情報を持つことになります。一箇所に情報があれば、常にそこが正であることを保証することができます。

訪問者は誰?

第三回で、アクセスしてきた人が誰なのかを確認する、「認証」について扱いました。システム側では、アクセスしてきた人が誰なのかを同定し、その人が正しく登録済みの人であるのか確認する必要があります。それが認証です。第二回で説明した「保存」の機能で保持されている「Identity情報」と「アクセスした人」が合致しているか、様々な方法で確認します。

どのサービスを使わせるか

第四回では、認証によって判明したユーザに対して、どのようなサービスを使わせるかを管理する「認可」を扱いました。実際の運用を考えると、
  • 営業担当者には、Salesforceを使わせる
  • サポート担当者には、Zendeskを使わせる
  • 全社員に、G SuiteとSlackを使わせる。
というように、グループに対して、サービスを「認可」することができます。これは、どのユーザがどのグループに属しているかという情報が、IDaaSに「保存」されているためです。

使えるように準備する

第五回では、「プロビジョニング」について扱いました。プロビジョニングが出来ない場合は、対象サービス側の管理画面から、アカウントを作る必要がありますが、プロビジョニングに対応している場合は、連携するサービスに対して、「アカウントの作成・更新・削除」をすることが出来ます。
つまり、IDaaSにアカウントを作成し、対象サービスを認可することで、対象サービス側には、アカウントが作成されますし、認可を取り消せば、削除(あるいは無効化)されることになります。または、認可をグループで管理していれば、特定のグループに所属させることで、対象サービスにアカウントが作成され、グループから外せば、削除(あるいは無効化)されます。ここが自動化されていない場合は、運用において大きな違いがあります。

利便性とセキュリティの両立

第六回では、「シングルサインオン」について扱いました。シングルサインオン(SSO)は、利用者の側からの視点と、管理者からの視点でその意味が大きく異なります。利用者の視点に立つと、
  • 一度ログインすれば、使って良いサービスはすべて使える
  • ID/パスワードをそれぞれ別々に覚えなくても良い
という利点があります。また、管理者にとっては、ユーザが杜撰なパスワード管理をする可能性が低くなる点と、サービス利用の停止が容易である等の利点があります。

運用例にあてはめます

前回までの内容を簡単にまとめてみました。これらの機能は、それぞれ他の機能を利用する立場にあります。ここまでの説明で断片的に出ていますが、全体としてどのように動くのか、簡単な運用例にあてはめてみましょう。登場するのは、「管理者」「利用者」「IDaaS」「サービス」です。
  1. 管理者は、IDaaSに利用者のアカウントを作成する。
  2. 管理者は、IDaaSで、利用者に連携するサービスを認可する。
  3. 利用者は、IDaaSのログイン画面から、ログインする。
  4. 利用者は、サービスを利用する。
この流れを少し詳細に見てみます。1.で利用者の「Identity情報」がIDaaSに保存されます。この段階では、まだIDaaSにあるだけです。2.の認可により、プロビジョニング機能を使って、連携するサービスにアカウントが作成されます。3.では、認証機能により、ログインして、シングルサインオンにより、対象機能にログインしていることになります。これらの機能が協調することで、4.で利用者はサービスを利用することができます。では、もう少し複雑な例として、利用者が他の部署に異動する例を考えましょう。具体的な方が分かりやすいので、以下のような例を想定します。
  • 「山田太郎」が「開発部」から「営業部」に異動する。
  • 開発部では、Slackを利用する。
  • 営業部では、Salesforceを利用する。
  • 全社員が、G Suiteを利用する。
異動のタイミングでの管理者の処理から始まります。ただし、前提条件として、
  • 開発部グループには、Slackが認可されている。
  • 営業部グループには、Salesforceが認可されている。
  • 全社員グループには、G Suiteが認可されている。
という設定がされているものとします。
  1. 管理者は、IDaaS上で、開発部グループのメンバーから、山田太郎を削除する。
  2. 管理者は、IDaaS上で、営業部グループのメンバーとして、山田太郎を追加する。
  3. 山田太郎は、IDaaSのログイン画面から、ログインする。
  4. 山田太郎は、G Suite、Salesforceが利用でき、Slackが利用できない。
この流れも詳細に見てみます。1.でSlackの山田太郎アカウントは、プロビジョニング機能により、削除か無効化されます。削除か無効化としているのは、対象サービスや、IDaaSの仕様によるからです。どちらにしても、山田太郎は、Slackを使えなくなります。2.で、Salesforceに山田太郎アカウントが作成されます。これ以降は、前述の例と同様で、3.で認証機能により、ログインし、4.では、シングルサインオン機能によりG SuiteとSalesforceにはログインしている状態となっているので、そのまま利用可能です。一方で、以前は使えていたSlackは使えないということになります。

まとめ

「IDaaSとは何か」というテーマで、7回にわたってその機能について掘り下げみました。IDaaSという耳なれない言葉について、身近なものとして理解するための一助となればと思います。多くのクラウドサービスが、提供されていますが、それを有効に使うためには、クラウドサービスを管理、運用するためのサービスも必要になります。それがなければ、結局運用は破綻し、せっかく有用なサービスも使われないか、なりすましや、不正利用されることもあり得ます。
IDaaSは、ユーザにも、管理者にも非常に有用なサービスです。導入をご検討ください。弊社では、豊富な実績のあるIDaaSサービス「Gluegent Gate」を提供しています。IDaaSの必要性に納得いただけましたら、ぜひ、ご相談ください。


   Gluegent Gate

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のロール機能の設定方法についてご紹介しました。申請モデル側でのロール設定に関する活用方法については後日ご紹介したいと思います。