2017年10月31日火曜日

Gluegent Flow活用例:決裁金額に応じて承認/決裁を切り替えるには?

Gluegent FlowはG Suite(旧Google Apps)やOffice 365と連携し、クラウド上で様々なワークフローを実現できるサービスです。 ご導入頂いているお客様では既に様々な「お金」に関するワークフローをご利用いただいていることでしょう。
一般的には上長の承認・決裁が必要な稟議書、精算書などに関するものがほとんどかと思いますが、そのようなワークフローにおいて決裁金額に応じて処理を切替えたいという御要望をお受けすることがあります。
今回は、Gluegent Flowを使って決裁額に応じた承認ルートの分岐方法をご説明します。

決裁金額に基づく承認ルートの分岐方法

本記事では以下の稟議フローの一部を使って説明していきます。
例えば、申請者からの稟議申請に対して直属の上司である課長が承認・決裁する場合、その決裁額によって以下のように処理が分かれるものとします。
  1. 20万未満:課長による決裁ができる。
  2. 20万以上:承認のみ。決裁の判断は次の承認者・決裁者に委ねる。

課長は決裁金額に応じて承認者となる場合もあれば、決裁者になる場合もあります。
これは、決裁金額によってどちらか一方の処理を排他的に実行するものと考えることができます。
Gluegent Flowでは上記のようなケースを実現する場合、必要な処理を実行するボタンを追加し、そのボタン毎に有効/無効または表示/非表示の条件設定を行うことで、表現することができます。
以下、このボタン表示切替に必要な設定方法を説明します。
  • 経路毎に必要な処理を追加する
  • その経路で承認/決裁者が行うべき処理を「経路」→「(経路名)」→「実行可能な処理」に定義します。以下のスクリーンショットでは「承認」、「決裁」を処理するためのボタンを追加しています。
  
  • ボタン表示制御のためのスクリプトを指定する
  • 上記で追加したボタンの名称をクリックし、「ボタン表示切替」の編集リンクをクリックします。すると、スクリプト編集画面が開きますので、そこで判定処理のためのスクリプトを記述します。
    例えば、「決裁」ボタンは入力フォームの項目「決裁金額」が20万未満の場合のみ表示するようにしたい場合、以下のようなスクリプトを記述します。
// 決裁ボタンの表示制御用スクリプト
// 20万未満の場合、表示(true)
if ( ${決裁金額} < 200000 ) {
    return true;
} else {
    return false;
}
    同様に「承認」ボタンにも表示制御用スクリプトを指定します。承認ボタンの場合は上記のスクリプトとは逆の条件判定になります。なお、スクリプトを記述したら、「スクリプトを確認する」リンクをクリックし、動作検証を行いましょう。
// 承認ボタンの表示制御用スクリプト
// 20万以上の場合、表示(true)
if ( ${決裁金額} >= 200000 ) {
    return true;
} else {
    return false;
}
    指定すると、各ボタン名に以下のようなアイコンが表示されます。

    以上の設定内容を踏まえた申請モデル「稟議書」を作ってみました。以下のスクリーンショットでは「費用または金額」が決裁金額に該当するものとします。
    例えば、申請者がタブレット購入額として160,000円を稟議申請した場合、20万未満となりますので、課長承認時には以下のように決裁ボタンのみ表示します。
パターンA:決裁金額が20万未満の場合(→決裁)


    一方、申請者がノートPC購入額として360,000円を稟議申請した場合は、決裁金額が20万以上となりますので承認ボタンのみ表示します。
パターンB:決裁金額が20万以上の場合(→承認)

    以上の通り、決裁金額による条件判定でボタンが切り替わることがお分かりいただけたと思います。

ボタン表示制御を利用するメリット

Gluegent Flowのボタン表示制御を利用することで以下のメリットを享受できます。
  • ユーザの誤認識による間違ったボタンの押下リスクが防止できる
    • 画面上に説明や注意書をどれだけ記載したとしても、人はミスする生き物であり、ミスは防ぎきれないでしょう。適切にボタン表示切替を利用することで、余計なボタンを押さず、ミスを防止することができます。
  • ワークフローを一元管理できる
    • 適切にボタン表示切替機能を指定することで、申請モデルを複数分ける必要はありません。
  • ユーザの学習コストおよび情報システム部のサポートコストが下がる
    • 画面のボタン表示もシンプルとなり、ユーザの教育コストおよび情報システム部門のサポートコストも下がることにつながるでしょう。

以上、Gluegent Flowのボタン表示制御機能を利用することで承認経路を変更する方法をご紹介しました。お客様へご説明するとき、「え?スクリプト?難しいんじゃない?」と不安がられることもありますが、書き方を少し覚えていただければ、すぐご活用いただけると思います。またスクリプト形式で記述できるからこそ、様々な条件判定が記載でき、拡張性も高いです。なお、注意点としましては、稟議書の申請モデルを1本にするために複雑な判定処理を記述してしまうと、ボタン毎に同様の記述が必要となり、修正発生時のメンテナンスが大変になる場合もあります。そのため、運用とメンテナンスを考慮しつつ、申請モデルを1本にまとめるべきか、分けるべきかご検討いただければと思います。



2017年10月24日火曜日

Gluegent Gateの運用パターン - シングルサインオン編 -

以前の記事「Gluegent Gateの運用パターン - アクセス制御編 -」において、Gluegent Gate でアクセスを制御する運用のパターンをいくつかご紹介しました。今回は、もう一方の主要機能「シングルサインオン」についての運用パターンを見ていきます。

 Gluegent Gate

シングルサインオン

シングルサインオン(SSO)とは、簡単に表現すると、「一回のログインをもって、複数のサービスを利用可能にする」という仕組みです。Gluegent Gate では、高度な連携が出来る既定のサービスをはじめとして、SAML2.0に対応するサービスや、SAML2.0に対応していない一般的なWebサービスも、SSOの対象サービスとして登録することができます。Gluegent Gate にログインすることでこれらのサービスに個別にログインすることなく、利用することができます。SSOの世界では、認証する役割をID Provider (IdP)、利用したいサービスをService Provider(SP)と言います。ここでは、Gluegent Gate が、IdPで、登録されるサービスがSPということになります。以下にGluegent Gate が扱えるSPを簡単にご紹介します。

1. 既定のSP
Gluegent Gate では、多くのサービスが既定のSPとして利用可能です。SSOの文脈では認証の連携をするのみですが、既定のサービスでは、認証以外にも、プロビジョニングの機能を提供するなど、より高度な連携が可能です。現時点では、G Suite、Office 365、cybozu.com、Box、Dropbox、Salesforce、Mail Luck!、PrimeDriveなどに対応しています。

2. SAML2.0対応のSP
SAML2.0は、SSOの仕様として事実上の標準となっており、多くのサービスがSPとして動作します。ただ、仕様として定められているものの、実際の実装にはサービス毎に若干のばらつきがあります。Gluegent Gate では、個別の設定をすることでSPとして登録することが出来ます。

3. SAML2.0に対応していないSP
SAML2.0に対応していなくても、SPとして登録することができます。そのサービスのログインURLとユーザIDのパラメータなどを設定することで、Gluegent Gate が代理で認証します。昨今の多くのサービスはSAMLに対応していますが、古くから社内で使われているサービスや、SSOを意図していない内製のサービスなどは、この方式でSPとして登録することができます。

実際の運用パターン

Gluegent Gateでは前述したSPを利用することができますが、お客様は実際にどのように運用されているのでしょうか。以下、お客様環境での運用ケースをご説明していきます。

代理認証でレガシー対応

まず、G Suiteや、Office 365といったメジャーなクラウドサービスの利用のために、アクセス制御を目的として導入するケースが多くあります。これまで、社内にサーバを置いてグループウェアを利用していたお客様が、G SuiteやOffice 365に移行する場合、多くのニーズは、移行先で満たせます。ただ、業務の内容によっては、どうしても既存のサービスを利用しなければいけない場合があります。その場合には、「既定のSPでクラウド型グループウェア 、代理認証で 既存サービス」というような運用となります。既存サービスを置き去りにせず、SSOの世界に入れることで、利便性が損なわれることがありません。

汎用SAMLで各種クラウドサービスをトッピング

クラウドサービスが当たり前の状況となってから、G SuiteやOffice 365のような多機能なサービスとは別に、特定の単機能に特化したサービスも多く提供されています。多くのお客様は、一般的なオフィススイートとして、G Suiteか、Office 365を使い、足りない部分を単機能のクラウドサービスで補うような運用をされています。全社員向けに、G Suiteを入れて、営業部門にはSalesforceを、サポート部門にはZendeskを、経理部門にはさらに別なクラウドサービスをというように、各部門向けに特化したサービスを選んで追加する形です。
ニーズは各部門にあるので、部門独自で導入してしまうケースも見受けられます。ただ、その場合は、ID管理が別になりますし、全社で使っているサービスと部門で使っているサービスは別にログインしなければいけません。その場合は、SPとして登録して、SSOの仲間にしてしまいます。メジャーなサービスは既定のSPとして提供しています(今後も対応を増やしていきます)し、現時点で対応できていなくても、汎用SAMLを利用すれば、SPとして登録可能です。
高度な機能が月単位で少人数でも利用可能になっている時代です。トッピング感覚でSSOに取り込むことでシームレスにサービスを利用できます。

シングルサインオンでユーザの利便性を追求し、さらに...

ビジネスで使うサービスは、今後も増加していきますし、捨てきれないレガシーサービスもあります。これらをまるっとSSOに取り込むことで、利用者は本来の仕事のために頭と時間を使うことができます。さらに、認証を一箇所で管理することで、前回の記事で触れた「アクセス制御」も一元管理できます。もうひとつのポイントの「ID管理」も一箇所で完結します。ユーザの利便性を追求することと、セキュリティの強化および、管理工数の削減を同時に実現可能です。


いかがだったでしょうか。Gluegent Gate は、レガシーシステムも、最新のクラウドサービスも同時に利用するお手伝いができます。是非一度ご相談ください。

 Gluegent Gate


2017年10月17日火曜日

Gluegent Gadgets の G Suite の「新しいサイト」対応について

2016年に、G Suite の「新しいサイト」が利用できるようになりました。「新しいサイト」は、これまでのサイトの延長線上には無く、コンセプトから何から大幅に変更されています。色々便利になっている反面、いくつかの不安な点もありました。特に、弊社として気を揉んでいたのは、Gluegent Gadgets はじめ埋め込み型の「ガジェット」の挿入の可否についてでした。



「新しいサイト」と「以前のサイト」についての Google社 からの公式アナウンスは、およそ以下の通りでした。

  • 2017 年に、以前の Google サイトから新しい Google サイトへ移行するためのおすすめの方法を提供予定
  • 2018 年より、以前の Google サイトの段階的なサービス終了について、日程や詳細な情報のお知らせを開始予定
  • 現段階では具体的なサービス終了日は確定しておりませんが、終了日の少なくとも 1 年前にはお知らせを実施
一方で、ガジェットについては、以下のような情報がありました。

Google Cloud Connect (G Suite 管理者向けの公式オンライン コミュニティ) の情報

- What kind of security is in place in the new Sites? -
For customers with classic Sites that have code from outside their domain (including third-party gadgets), we provide additional protections for those embeds. Upon launch, the new Sites will not have gadgets and instead, will have embeds with content from other sources in an iframe, or using the OpenGraph protocol, neither of which pose a security risk.

弊社からの Google Support への問合せ結果

貴社を含め多くのパートナー様がガジェットを提供いただいている状態であるため、そう簡単に廃止できる機能でないとは思っておりますが、現時点でははっきりとしたことは申し上げられません。


この度、上記の状況に動きがありましたので、ここで紹介させていただきます。

2017年9月13日に、Google社 より新しいサイトでのガジェットへの対応ということで、以下の記事が掲載されました。


この情報により、弊社Gluegent Gadgets についても、新しいサイトで利用していただくことができるだろうとの判断の下、現在対応可否の詳細について調査を進めております。

同時に「新しいサイト」の売りでもある、「レスポンシブ Web デザイン」(PC、スマートフォン、タブレット等でも柔軟にデザインが調整されるウェブサイト) に対応させることも検討しております。

みなさまに、新しいサイトに対応した Gluegent Gadgets をお届けできるよう、邁進いたします。



2017年10月10日火曜日

Gluegent Gateはなぜ細かいアクセス制御が実現できるのか?

Gluegent Gateは G SuiteやOffice 365等の様々なクラウドサービスに対して、SSOやアクセス制御を実現することができるセキュリティサービスです。Gluegent Gateでは、接続サービス、認証方式、時間帯、ネットワーク、端末種類など対するアクセスルールを、ユーザやグループ毎に設定することができます。これにより細かいアクセス制御が可能となっています。今回は、そのアクセス制御を実現している仕組みについてご説明したいと思います。

Gluegent Gateで細かいアクセス制御が実現できる理由

認証・アクセス制御をご検討されている会社の場合、社内のユーザに対して、部署、業務、利用しているクライアント端末などに応じて、利用するサービスや認証方法を変えたい場合もあるかと思います。
例えば、以下のようなアクセスポリシーを社内で設定したいとします。
  • G Suiteは社員全員が利用できるものとしする。
    • アクセス時のクライアント端末は社内のPCブラウザからのアクセスを基本とするが、社外からの利用は会社が許可した端末からのみアクセス可能とする。
  • その他、営業部に所属する社員はSalesforceへアクセスできる
このようなポリシーを踏まえて適切なアクセス制御を行いたい場合、「誰が」「どの端末で」認証しようとしているかに加えて、「誰が」「どの端末で」「どこに」アクセスしようとしているかもチェックする必要があります。
Gluegent Gateではこのようなチェックを適切に行えるようにするために、認証を行ったユーザを識別し、ある特定のユーザ・グループに対してアクセス先サービスを限定したり、端末毎に認証方式を変更する必要があります。 これを実現するために、Gluegent Gateでは認証フェーズと認可(アクセス権限)フェーズの2フェーズに分けて処理するようになっており、これにより細かいアクセス制御が可能となっています。

下図は、認証/認可処理フェーズの流れをまとめたものです。
以下に各フェーズ毎の処理概要を説明します。

1. 認証フェーズ

認証フェーズでは管理者が定義した認証ルールに基づき、ログインを試みるユーザーが誰であるかを特定するものになります。
  • 認証ルールは、どの端末種類からの認証時にどの認証方式を要求するか定義します。
  • 認証方式は、ID・パスワード認証、証明書認証、端末認証、AD/LDAP認証等を指定します。
  • 認証ルールに複数該当していたとしても、最初に認証が失敗した時点で即認証エラーとなります。
  • なお、Gluegent Gateではログインに成功した情報を保持し、別の対象サービスへのアクセスに際して再認証の必要なくログインが可能です(SSOの実現)

2. 認可(アクセス権限)フェーズ

認可(アクセス権限)フェーズでは、上記1の認証フェーズで特定されたユーザに対して、管理者が定義したアクセス権限ルールに基づき対象サービスへのアクセス権があるかチェックします。
  • アクセス権限ルールは、ユーザ、グループ、場所(ネットワーク)、日時、端末種類等といった条件を組み合わせて定義します。
  • 認証が成功したユーザは設定されたいずれかのルールにマッチするアクセス手段であれば、アクセス成功とみなします。
  • いずれのルールにもマッチしなかった場合は、アクセス失敗となり、対象サービスを利用することができません。
アクセス権限の詳細については以下の記事をご確認ください。
Gluegent Gateの運用パターン - アクセス制御編 -


いかがだったでしょうか。Gluegent Gateでは認証・認可の2フェーズに分けていることで細かいアクセス制御が可能となることがお分かりいただけたと思います。もし、別のセキュリティサービスを使っており、アクセスポリシーを細かく設定したいができない点でお困りの方がいらっしゃいましたら、ぜひお問い合わせください。

 Gluegent Gate


2017年10月3日火曜日

細かい配慮で利用者にやさしいワークフローを実現するには?

Gluegent Flow は、G SuiteやOffice 365と連携して、多様な「ワークフロー」をクラウドで実現することができます。これまでに、多くのお客様のご要望を実現しするために、きめ細やかな機能を実装してきました。ただ、お客様がやりたいことは千差万別で、全てを実装済みの機能としてご提供するのは困難です。そこで、Gluegent Flowでは、一部の機能でお客様自身が拡張できる仕組みをご用意しています。今回はそのような拡張の実例をご紹介します。

細かな入力チェック

申請者は、フォームに入力する時に様々な値を入れます。ワークフローとしては、数値を期待しているのに、文字列が入れられたりすると、後続の処理で困るため、手で直さなければならない場合もあるでしょう。そのため、入力フォームでは、入力された値をチェックする「入力チェック(バリデーション)」という機能が必要です。
以下の例で、フォームにメールアドレスが入力されることを期待する入力チェックをご紹介します。

カスタムバリデーション

入力チェックのルールをJavaScriptで実現します。申請モデルの入力チェックのカスタムバリデーションの「スクリプト」で、入力された値が、期待されたものなら、trueを返し、そうでない場合には、falseを返すようにします。
custom_validation.png


メールアドレスが期待される場合には、以下のようなスクリプトになります。入力された値が、メールアドレスを示す文字列にマッチしない場合に、falseを返しています。


// 未入力チェック
if (${メールアドレス} == undefined) {
 // 未入力の場合は、以下のチェックは行わず、正常とする
 return true;
}
// 形式チェック
if (!${メールアドレス}.match(/^[A-Za-z0-9]+[\w-]+@[\w\.-]+\.\w{2,}$/)){
 // !は否定(〜でない)。この場合、match(xxx)で xxx に該当するものでないとなる。
 return false;
}
return true;

「スクリプトを確認する」の機能を使って、その場で動作の確認をすることもできます。
任意のスクリプトを設定することで、入力値が、定められた形式(社員番号や商品コードなど)であることをチェックできます。また、スクリプト内では、他の入力フォームで入力された値や、日付、申請者の情報などを参照することもできますので、より柔軟なチェックが可能です。

入力された値に対応したメッセージを表示する

上の例は、入力される値を期待するものに限定する機能でした。次の例は、入力された値に対応して、特定のメッセージを表示する機能です。ここでも、JavaScriptが使えます。

カスタムラベル

入力フォームの形式として「カスタムラベル」を使います。特定の値を参照して、定義した条件に合致した場合に、特定の文字列を返します。返された文字列が、申請フォームに表示されます。
custom_label.png


以下の例では、処理した日付を参照して、曜日を表示することができます。


var today = new Date( ${処理年月日});
var label = ["日","月","火","水","木","金","土"];
return label[today.getDay()] + "曜日";

スクリプトを確認してみましょう。確認するために任意の日付を入れられますが、実際の申請時には、プレースホルダの機能によって、申請された日付が自動で入ることになります。
custom_label_test.png

細かい配慮で使いやすいワークフローを提供できます

Gluegent Flowでは、様々な機能でJavaScriptを使って、機能を拡張することができます。申請フォームの作りの柔軟さは、利用者の利便性を大きく左右します。申請者が迷わずに必要な値を入力し、迅速に処理をすすめられるワークフローを提供するために、ぜひ、Gluegent Flowをご利用ください。