FIWARE Banner

FIWARE Security License: MIT Support badge FIWARE Security
Documentation

このチュートリアルでは、追加のセキュリティ Generic Enabler の Authzforce を紹介し、Keyrock によって生成されたセキュリティ・ルールにきめ細かい制御を 追加します。以前のチュートリアル で作成したエンティティへのアクセスは、XACML アクセス制御ポリシーを使用して構成 および制御されます。これにより、実行中にアップロードおよび再解釈できる柔軟な ルールセットが作成されるため、複雑なビジネス・ルールを作成および変更できます。

チュートリアルでは、Authzforce を Web アプリケーションに統合する方法を示す コードについて説明し、Authzforce XACML Server-PDP とのやり取りの例を示します 。cUrl コマンドは、Generic Enablers 間の相互作用を示す ために使用されます。 Postman documentation が利用できます。

Run in Postman


ルールセットベースの権限

"Say: Come, I will rehearse what Allah hath prohibited you from:

  • Join not anything as equal with Him
  • Be good to your parents
  • Kill not your children on a plea of want - We provide sustenance for you and for them
  • Come not nigh to shameful deeds. Whether open or secret
  • Take not life, which Allah hath made sacred, except by way of justice and law

thus doth He command you, that ye may learn wisdom."

— Quran 6.151, Sūrat al-Anʻām

以前のチュートリアル では、認証に基づく単純なアクセス制御システム (レベル1)、またはロールに基づく リソースへの基本的な認可アクセス (レベル2) を紹介しました。これらのポリシーは 簡単に作成できますが、その中のルールは非常に白と黒で、ルールを相互に依存したり、 例外条項を設定したり、期限や属性値に基づいてアクセスしたりすることはできません。 衝突が発生した場合に異なるルールを解決するメカニズムもありません。

複雑なアクセス制御シナリオを満たすには、追加の調停マイクロサービスが必要です。 これは、アクセス制御ルールの全セットを読んで解釈し、リクエストしているサービス によって提供された証拠に基づいて、各許可/拒否ポリシー決定に関する判断を下すこと ができます。

FIWARE Authzforce は、 そのような解釈的なポリシー決定ポイント (PDP : Policy Decision Point) を提供する ことができるサービスです。これは、 XACML 標準 を使用して提供されたルールを解釈できる高度なアクセス制御の Generic Enabler です 。ルールセットはいつでも修正およびアップロードでき、ビジネス・ニーズに応じて 変更できるセキュリティ・ポリシーを維持するための柔軟な方法を提供します。さらに、 アクセス・ポリシーを記述するために使用される言語は、非常に拡張性が高く、 あらゆるアクセス制御シナリオをカバーするように設計されています。

XACML とは

eXtensible Access Control Markup Language (XACML) は、ベンダーに依存しない 宣言型アクセス制御ポリシー言語です。これは、一般的なアクセス制御の用語と 相互運用性を促進するために作成されました。ポリシー実行ポイント (PEP : Policy Execution Point) やポリシー決定ポイント (PDP) などの要素の アーキテクチャの命名ルールは、XACML 仕様に基づいています。

XACML ポリシーは、<PolicySet>, <Policy><Rule> の3つのレベルの 階層に分けられます。<PolicySet> は、それぞれが一つ以上の <Rule> 要素を 含む <Policy> 要素の集合です。

<Policy> 内の各 <Rule> は、それがリソースへのアクセスを許可すべきか どうかに関して評価されます。総合的な <Policy> 結果は、順番に処理された すべての <Rule> 要素の総合的な結果によって定義されます。そして、別々の <Policy> 結果は、衝突の場合にどちらの <Policy> が勝つかを定義する 組み合わせアルゴリズムを使用してお互いに対して評価されます。

<Rule> 要素は <Target><Condition> から成ります。これは <Rule> の例です。POST リクエストが /bell/ring エンドポイントに送信され、 subject:rolerole=security-role-0000-0000-000000000000 が提供されて いれば、アクセスには、(Effect="Permit") を与えられることを示しています。

<Rule RuleId="alrmbell-ring-0000-0000-000000000000" Effect="Permit">
  <Description>Ring Alarm Bell</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/bell/ring</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">POST</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
      <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">security-role-0000-0000-000000000000</AttributeValue>
      <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false" />
    </Apply>
  </Condition>
</Rule>

これは、XACML を使用した単純な Verb-Resource アクセス・ルールを作成するための 非常に冗長な方法ですが、単純な Verb-Resource ルールとは異なり、より複雑な 比較を行うことができます。たとえば、時刻が特定の時間より前であることを確認 したり、URL が特定の文字列で始まっていたり、特定の文字列を含んでいたりする ことを確認します。条件は属性レベルまで指定することも、複雑な計算をするために 組み合わせることもできます。 たとえば、次のポリシーを適用するために XACML の <Rule> を作成できます。

ストア・マネージャは、月の初めにのみ商品の価格を修正することができます。 また、直属の上司が最初に作成した商品の価格のみを変更することができます

そのような <Rule> は、<Condition> が次のために別々の条項/明確化を 含むことを要求するでしょう :

  • ユーザのロールは何ですか? (例 : manager)
  • どんなアクションが呼び出されていますか? (例 : PATCH または PUT)
  • どのリソースが保護されている URL 文字列ですか。 (例 : /v2/entities)
  • リクエストのボディには他にどのような情報が必要ですか? (例 : エンティティ typeProduct に等しくなければなりません)
  • リソースはいつリクエストされていますか? (例 : 現在の日付)
  • リクエストを出す前に、他の場所から他にどのような追加情報を取得する 必要がありますか
    • 誰がエンティティを作成しましたか? 私ですか、それともマネージャ (上司) ですか?

ご覧のとおり、これらのルールはすぐに非常に複雑になることがあります。この XACML の最初のイントロダクションでは、不要な混乱を避けるために使用される基本的 なルールセットはできるだけ単純に保ちます。XACML に基づくアクセスポリシーは、 複雑なシステムのセキュリティ・ニーズに合わせて拡張できると言うために十分です。

前提条件

Docker

物事を単純にするために、両方のコンポーネントが Docker を使用して実行されます。Docker は、さまざまコンポーネントをそれぞれの環境に 分離することを可能にするコンテナ・テクノロジです。

  • Docker Windows にインストールするには 、こちらの手順に従ってくださ い
  • Docker Mac にインストールするには 、こちらの手順に従ってください
  • Docker Linux にインストールするには 、こちらの手順に従ってください

Docker Compose は、マルチコンテナ Docker アプリケーションを定義して実行する ためのツールです。 YAML file ファイルは、アプリケーションのために必要なサービスを構成するために使用します。つ まり、すべてのコンテナ・サービスは 1 つのコマンドで呼び出すことができます 。Docker Compose は、デフォルトで Docker for Windows と Docker for Mac の一部と してインストールされますが、Linux ユーザは ここに記載されている手順に従う必要 があります。

Cygwin

シンプルな bash スクリプトを使用してサービスを開始します。Windows ユーザは cygwin をダウンロードして、Windows 上の Linux ディストリビューションと同様のコマンドライン機能を提供する必要があります。

アーキテクチャ

このアプリケーションは、 以前のチュートリアル で作成した既存の在庫管理 およびセンサ・ベースのアプリケーションにレベル3の 高度な認可のセキュリティを追加し、 PEP Proxy の背後にある Context Broker へのアクセスを保護します。 Orion Context Broker, IoT Agent for UltraLight 2.0, Keyrock Identity Manager, Wilma PEP Proxy, Authzforce XACML Server の5つの​​ FIWARE コンポーネントを利用します。すべてのアクセス制御の決定は、 以前にアップロードされたポリシー・ドメインからルールセットを読み取る Authzforce に委任されます。

Orion Context Brokerと IoT Agent はどちらも、オープンソースの MongoDB テクノロジを使用して、保持している情報を 永続化します。また、 以前のチュートリアル で作成したダミー IoT デバイスも使用します。Keyrock は、独自に MySQL データベースを使用しています。

したがって、アーキテクチャ全体は次の要素から構成されます :

  • FIWARE Orion Context Broker は 、NGSI を使用 してリクエストを受信します
  • FIWARE IoT Agent for Ultralight 2.0 は、 Ultralight 2.0 フォーマットのダミー IoT デバイスからノース・バウンドの測定値を受信し、 Context Broker がコンテキスト・エンティティの状態を変更するための NGSI リクエストに変換します
  • FIWARE Keyrock は、以下を含 んだ、補完的な ID 管理システムを提供します :
    • アプリケーションとユーザのための OAuth2 認証システム
    • ID 管理のための Web サイトのグラフィカル・フロントエンド
    • HTTP リクエストによる ID 管理用の同等の REST API
  • FIWARE Authzforce Orion やチュートリアル・アプリケーションなどのリソースへのアクセスを 保護する解釈可能な Policy Decision Point (PDP) を提供する XACML Server です
  • FIWARE Wilma Orion マイクロサービスへのアクセスを保護する PEP Proxy プロキシです。 認可決定の受渡しを Authzforce PDP に委任します
  • MongoDB データベース :
    • Orion Context Broker が、データ・エンティティ、サブスクリプション、 レジストレーションなどのコンテキスト・データ情報を保持するために使用しま す
    • デバイスの URLs や Keys などのデバイス情報を保持するために IoT Agent によって使用されます
  • MySQL データベース :
    • ユーザ ID、アプリケーション、ロール、および権限を保持するために使用され ます
  • 在庫管理フロントエンドには、次のことを行います :
    • 店舗情報を表示します
    • 各店舗でどの商品を購入できるかを示します
    • ユーザが製品を"購入"して在庫数を減らすことができます
    • 許可されたユーザを制限されたエリアに入れることができます。認可の決定を Authzforce PDP に委任します
  • HTTP を介して実行されている UltraLight 2.0 プロトコルを使用す るダミー IoT デバイスのセ ットとして機能する Web サーバ。特定のリソースへのアクセスが制限されています 。 要素間のやり取りはすべて HTTP リクエストによって開始されるため、 エンティティをコンテナ化して公開ポートから実行することができます。

チュートリアルの各セクションの具体的なアーキテクチャについては、 以下で説明します。

Keyrock の設定

keyrock:
    image: fiware/idm
    container_name: fiware-keyrock
    hostname: keyrock
    networks:
        default:
            ipv4_address: 172.18.1.5
    depends_on:
        - mysql-db
        - authzforce
    ports:
        - "3005:3005"
    environment:
        - DEBUG=idm:*
        - DATABASE_HOST=mysql-db
        - IDM_DB_PASS_FILE=/run/secrets/my_secret_data
        - IDM_DB_USER=root
        - IDM_HOST=http://localhost:3005
        - IDM_PORT=3005
        - IDM_ADMIN_USER=alice
        - IDM_ADMIN_EMAIL=alice-the-admin@test.com
        - IDM_ADMIN_PASS=test
        - IDM_PDP_LEVEL=advanced
        - IDM_AUTHZFORCE_ENABLED=true
        - IDM_AUTHZFORCE_HOST=authzforce
        - IDM_AUTHZFORCE_PORT=8080
    secrets:
        - my_secret_data

keyrock コンテナは、単一のポートでリッスンしている、Web アプリケーション・サーバです :

  • ポート 3005 は HTTP トラフィック用に公開されているため、Web ページを表示して REST API で対話できます

keyrock コンテナは、Authzforce に接続していて、次のように、環境変数によって駆動されます。

キー 説明
IDM_PDP_LEVEL advanced Keyrock が PDP の決定を Authzforce に委任すべきであることを示すフラグ
IDM_AUTHZFORCE_ENABLED true Authzforce が利用可能であることを示すフラグ
IDM_AUTHZFORCE_HOST authzforce Authzforce の URL
IDM_AUTHZFORCE_PORT 8080 Authzforce がリッスンしているポート

YAML ファイルに記述されている他の keyrock コンテナ設定値は以前のチュートリアルで説明されています。

PEP Proxy の設定

orion-proxy:
    image: fiware/pep-proxy
    container_name: fiware-orion-proxy
    hostname: orion-proxy
    networks:
        default:
            ipv4_address: 172.18.1.10
    depends_on:
        - keyrock
        - authzforce
    ports:
        - "1027:1027"
    expose:
        - "1027"
    environment:
        - PEP_PROXY_APP_HOST=orion
        - PEP_PROXY_APP_PORT=1026
        - PEP_PROXY_PORT=1027
        - PEP_PROXY_IDM_HOST=keyrock
        - PEP_PROXY_HTTPS_ENABLED=false
        - PEP_PROXY_IDM_SSL_ENABLED=false
        - PEP_PROXY_IDM_PORT=3005
        - PEP_PROXY_APP_ID=tutorial-dckr-site-0000-xpresswebapp
        - PEP_PROXY_USERNAME=pep_proxy_00000000-0000-0000-0000-000000000000
        - PEP_PASSWORD=test
        - PEP_PROXY_PDP=authzforce
        - PEP_PROXY_AUTH_ENABLED=true
        - PEP_PROXY_MAGIC_KEY=1234
        - PEP_PROXY_AZF_PROTOCOL=http
        - PEP_PROXY_AZF_HOST=authzforce
        - PEP_PROXY_AZF_PORT=8080

orion-proxy コンテナは ポート 1027 でリッスンしている、FIWARE Wilma のインスタンスです。orion の ポート 1026 にトラフィックを転送するように設定されています。これは、Orion Context Broker が NGSI リクエストを待ち受けているデフォルト・ポートです。

orion-proxy コンテナは、PDP の決定を Authzforce を委任しており、次に示すように環境変数によって駆動されます。

キー 説明
PEP_PROXY_PDP authzforce PEP Proxy が Authzforce を PDP として使用するようにするためのフラグ
PEP_PROXY_AZF_PROTOCOL http Authzforce が使用するプロトコル
PEP_PROXY_AZF_HOST authzforce Authzforce の URL
PEP_PROXY_AZF_PORT 8080 Authzforce がリッスンしているポート

YAML ファイルに記述されている他の orion-proxy コンテナの設定値は、 以前のチュートリアルで説明されています。

Authzforce の設定

authzforce:
    image: fiware/authzforce-ce-server
    hostname: authzforce
    container_name: fiware-authzforce
    networks:
        default:
            ipv4_address: 172.18.1.12
    ports:
        - "8080:8080"
    volumes:
        - ./authzforce/domains:/opt/authzforce-ce-server/data/domains

authzforce コンテナは、ポート 8080 で待機しています。これは PDP の決定を行うためにリクエストを受け取ります。一連の XACML アクセス制御ポリシーがすでに提供されているように、volume は事前構成されたドメインをアップロードするために公開されています。

チュートリアルのセキュリティ設定

tutorial:
    image: fiware/tutorials.context-provider
    hostname: tutorial
    container_name: fiware-tutorial
    networks:
        default:
            ipv4_address: 172.18.1.7
    expose:
        - "3000"
        - "3001"
    ports:
        - "3000:3000"
        - "3001:3001"
    environment:
        - "DEBUG=tutorial:*"
        - "WEB_APP_PORT=3000"
        - "KEYROCK_URL=http://localhost"
        - "KEYROCK_IP_ADDRESS=http://172.18.1.5"
        - "KEYROCK_PORT=3005"
        - "KEYROCK_CLIENT_ID=tutorial-dckr-site-0000-xpresswebapp"
        - "KEYROCK_CLIENT_SECRET=tutorial-dckr-site-0000-clientsecret"
        - "CALLBACK_URL=http://localhost:3000/login"
        - "AUTHZFORCE_ENABLED=true"
        - "AUTHZFORCE_URL=http://authzforce"
        - "AUTHZFORCE_PORT=8080"

tutorial コンテナは、2つのポートでリッスンしています :

  • ポート 3000 は公開されているため、Web ページにダミー IoT デバイスが表示されます
  • ポート 3001は純粋にチュートリアル・アクセスのために公開されているので、 cUrl や Postman は同じネットワークの一部でなくても Ultra Light コマンドを作成できます

tutorial コンテナは、Authzforce によってセキュリティが保護されており、 以下に示すように環境変数によって駆動されます。

キー 説明
AUTHZFORCE_ENABLED true XACML PDP の使用を有効にするためのフラグ
AUTHZFORCE_URL http://authzforce Authzforce の URL
AUTHZFORCE_PORT 8080 Authzforce がリッスンしているポート

YAMLファイルに記述されている他の tutorial コンテナ設定値は 以前のチュートリアルで説明されています。

起動

インストールを開始するには、次の手順に従います :

git clone git@github.com:Fiware/tutorials.XACML-Access-Rules.git
cd tutorials.XACML-Access-Rules

./services create

注: Docker イメージの最初の作成には最大 3 分かかります

services Bash スクリプトを実行することによって、コマンドラインからすべてのサービスを初期 化することができます :

./services start

注: クリーンアップをやり直したい場合は、次のコマンド を使用して再起動することができます :

./services stop

登場人物 (Dramatis Personae)

次の test.com のメンバは、合法的にアプリケーション内にアカウントを持っています

  • Alice, Keyrock アプリケーションの管理者です
  • Bob, スーパー・マーケット・チェーンの地域マネージャで、数人のマネージャがい ます :
    • Manager1 (マネージャ 1)
    • Manager2 (マネージャ 2)
  • Charlie, スーパー・マーケット・チェーンのセキュリティ責任者。彼の下に数人の 警備員がいます :
    • Detective1 (警備員 1)
    • Detective2 (警備員 2)

次のexample.com のメンバはアカウントにサインアップしましたが、アクセスを許可す る理由はありません

  • Eve - 盗聴者のイブ
  • Mallory - 悪意のある攻撃者のマロリー
  • Rob - 強盗のロブ

詳細(クリックして拡大)

名前 E メール パスワード
alice alice-the-admin@test.com test
bob bob-the-manager@test.com test
charlie charlie-security@test.com test
manager1 manager1@test.com test
manager2 manager2@test.com test
detective1 detective1@test.com test
detective2 detective2@test.com test
名前 E メール パスワード
eve eve@example.com test
mallory mallory@example.com test
rob rob@example.com test

Authzforce - バージョン情報の取得

Authzforce を実行すると、公開されている管理ポートに HTTP リクエストを 送信することでステータスを確認できます (通常 8080)。レスポンスがブランクの 場合、これは通常 Authzforce が実行されていないか別のポートで待機している ためです。

1 リクエスト

curl -X GET \
  http://localhost:8080/authzforce-ce/version \
  -H 'Accept: application/xml'

レスポンス

レスポンスは Authzforce のバージョンに関する情報を返します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<productMetadata xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
   xmlns:ns2="http://www.w3.org/2005/Atom"
   xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
   xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
   xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6"
   name="AuthzForce CE Server"
   version="8.0.1"
   release_date="2017-12-05"
   uptime="P0Y0M0DT0H8M47.642S"
   doc="https://authzforce.github.io/fiware/authorization-pdp-api-spec/5.2/"/>

XACML サーバを使用

Authzforce は、ポリシー決定ポイント (PDP : Policy Decision Point) Generic Enablerであり、 XACML で書かれた <PolicySet> 情報に基づいて認可の決定を下します。 この例は、既存の一連のルールを含む実行中の XACML server から開始します。 XACML server は、ポリシーを管理し、アクセス制御ポリシー決定を呼び出すための API を提供する必要があります。このチュートリアルは主に意思決定側に関係します。 アクセス制御ポリシーの作成と管理は後のチュートリアルで扱います。

XACML ルールセットの読み込み

単一の XACML server を使用して、複数のアプリケーションに対するアクセス制御 ポリシーを管理できます。Authzforce は暗黙のうちにマルチテナントなって います。つまり、別々の組織が互いから独立して彼らのポリシーを実現することが できます。これは、各アプリケーションのセキュリティ・ポリシーを、別々の ドメイン に分割し、そこでそれぞれ独自の <PolicySets> にアクセスできる ようにすることで行います。ドメインは、セキュリティで保護されたアプリケーション に関するメタデータとポリシー自体のバージョン (事実上、ファイル・サーバから アクセスできる一連のファイル) を保持します。ドメイン管理 API を使用して、 提供されるドメインと保持されているポリシーについて Authzforce に問い合わせることができます。

すべてのドメインをリスト

Authzforce にドメイン情報をリクエストするには、 /authzforce-ce/domains エンドポイントにリクエストを出します。

2 リクエスト

curl -X GET \
  http://localhost:8080/authzforce-ce/domains

レスポンス

レスポンスには、Authzforce で利用可能なドメインがリストされます。これは 起動時に Authzforce にアップロードされたディレクトリ構造に対応します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<resources xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <ns2:link rel="item" href="gQqnLOnIEeiBFQJCrBIBDA" title="gQqnLOnIEeiBFQJCrBIBDA"/>
</resources>

単一ドメインを読み込み

ドメインに関する情報を読み、さらに詳しく調べるには、 authzforce-ce/domains/{{domain-id}} エンドポイントにリクエストを出します。 次のリクエストでは、外部の Policy Administration Point によってランダム・キーを 使用して生成された gQqnLOnIEeiBFQJCrBIBDA ドメインに関する情報が取得されます。 この場合、Keyrock が PAP として使用され、 ルールセットが事前に生成されています。

3 リクエスト

curl -X GET \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA

レスポンス

レスポンスには、Keyrock (tutorial-dckr-site-0000-xpresswebapp) 内で使用されている id など、ドメインに関する詳細情報がリストされます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<domain xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <properties externalId="tutorial-dckr-site-0000-xpresswebapp"/>
    <childResources>
        <ns2:link rel="item" href="/properties" title="Domain properties"/>
        <ns2:link rel="item" href="/pap" title="Policy Administration Point"/>
        <ns2:link rel="http://docs.oasis-open.org/ns/xacml/relation/pdp"
          href="/pdp" title="Policy Decision Point"/>
    </childResources>
</domain>

ドメイン内で利用可能なすべてのポリシーセットをリスト

ドメイン内で見つかったすべての PolicySets に対して生成された ids をリストする には、authzforce-ce/domains/{{domain-id}}/pap/policies エンドポイントに リクエストを出します。次のリクエストは、gQqnLOnIEeiBFQJCrBIBDA ドメイン内で見つかった特定ポリシーの ids のリストを取得します。

4 リクエスト

curl -X GET \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pap/policies

レスポンス

レスポンスは、Authzforce コンテナ内で利用可能な、指定されたポリシーの 利用可能なリビジョンのリストを返します。これは、1.xml, 2.xml などの名前付き XML ファイルに対応します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<resources xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <ns2:link rel="item" href="f8194af5-8a07-486a-9581-c1f05d05483c"/>
    <ns2:link rel="item" href="root"/>
</resources>

PolicySet の利用可能なリビジョンをリスト

ポリシーの利用可能なリビジョンをリストするには、 authzforce-ce/domains/{{domain-id}}/pap/policies/{{policy-id}} エンドポイントにリクエストを出します。使用可能なポリシー id はランダムに 生成され、前のリクエストを使用してドリル・ダウンすることによって取得できます。 次のリクエストは、gQqnLOnIEeiBFQJCrBIBDA ドメイン内で見つかった特定ポリシー のリビジョンのリストを取得します。

5 リクエスト

curl -X GET \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pap/policies/f8194af5-8a07-486a-9581-c1f05d05483c

レスポンス

レスポンスは、Authzforce コンテナ内で利用可能な、指定されたポリシーの 利用可能なリビジョンのリストを返します。これは、1.xml, 2.xml などの名前付き XML ファイルに対応します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<resources xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <ns2:link rel="item" href="2"/>
    <ns2:link rel="item" href="1"/>
</resources>

PolicySet の単一バージョンを読み込む

<PolicySet> の単一のリビジョンを取得するには、 authzforce-ce/domains/{{domain-id}}/pap/policies/{{policy-id}}/{{revision-number}} エンドポイントにリクエストを出します。次のリクエストは、gQqnLOnIEeiBFQJCrBIBDA ドメイン内で見つかった特定のポリシーの2番目のリビジョンを取得します。

6 リクエスト

curl -X GET \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pap/policies/f8194af5-8a07-486a-9581-c1f05d05483c/2

レスポンス

レスポンスには、与えられたリビジョンのフルの <PolicySet> が含まれています。 これは Authzforce 内に保持されている ファイル のコピーです 。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:PolicySet xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6" PolicySetId="f8194af5-8a07-486a-9581-c1f05d05483c" Version="2" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit">
    <ns3:Description>Policy Set for application tutorial-dckr-site-0000-xpresswebapp</ns3:Description>
    <ns3:Target/>
    <ns3:Policy PolicyId="security-role-0000-0000-000000000000"
      Version="1.0"
      RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit">
        <ns3:Description>Role security-role-0000-0000-000000000000 from application tutorial-dckr-site-0000-xpresswebapp</ns3:Description>
        <ns3:Target>
           ...etc
        </ns3:Target>
        <ns3:Rule RuleId="alrmbell-ring-0000-0000-000000000000" Effect="Permit">
            ...etc
        </ns3:Rule>
        ..etc
    </ns3:Policy>
</ns3:PolicySet>

ポリシー決定のリクエスト

このチュートリアルの目的のために、Authzforce には、以前の Securing Access チュートリアルに見られるレベル2の認可の例と同様に、 単純な基本的なロール・ベースのルールのシンプル・セットが提供されています。

  • ドアのロック解除コマンドは、セキュリティ・スタッフのみが送信できます
  • 価格変更およびオーダー在庫エリアへのアクセスは、マネージャだけが 可能です
  • マネージャまたはセキュリティのロールを持つ人は、ベルを鳴らすこと ができます
  • マネージャセキュリティの両方がストア・データにアクセスして インタラクトすることができます。

唯一の違いは、すべてのストア・エンティティへのアクセスが、レベル1認証アクセス に基づくのではなく、割り当てられたロールを持つユーザに制限されるように なったことです。

Authzforce に決定をリクエストするには、すべての関連情報を含む 構造化リクエストを domains/{domain-id}/pdp エンドポイントに送信する必要が あります。この場合、リクエストのボディには、ユーザが持つロール、リクエスト されているアプリケーション id (tutorial-dckr-site-0000-xpresswebapp)、 リクエストされている HTTP 動詞とリソース (/app/price-change URL に対する GET リクエスト) などの情報が含まれています。明らかに、ボディで渡される情報は、 ルールが複雑になるにつれて拡張できます。

リソースへのアクセスを許可

Authzforce に決定をリクエストするには、domains/{domain-id}/pdp エンドポイントに POST リクエストを出します。この場合、ユーザは managers-role-0000-0000-000000000000 を持ち、 リソース /app/price-change へのアクセスをリクエストしています。

7 リクエスト

curl -X POST \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pdp \
  -H 'Content-Type: application/xml' \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
   <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">managers-role-0000-0000-000000000000</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">tutorial-dckr-site-0000-xpresswebapp</AttributeValue>
      </Attribute>
      <Attribute AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/app/price-change</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" />
</Request>'

レスポンス

managers-role-0000-0000-000000000000/app/price-change エンドポイントへのアクセスを許可します。成功したリクエストに対するレスポンスは リソースへのアクセスを許可するための <Decision> 要素を含みます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:Response xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <ns3:Result>
        <ns3:Decision>Permit</ns3:Decision>
    </ns3:Result>
</ns3:Response>

リソースへのアクセスを拒否

Authzforce に決定をリクエストするには、 domains/{domain-id}/pdp エンドポイントに POST リクエストを 出します。この場合、ユーザは security-role-0000-0000-000000000000 を持ち、リソース /app/price-change へのアクセスをリクエスト しています。

8 リクエスト

curl -X POST \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pdp \
  -H 'Content-Type: application/xml' \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
   <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">security-role-0000-0000-000000000000</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">tutorial-dckr-site-0000-xpresswebapp</AttributeValue>
      </Attribute>
      <Attribute AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/app/price-change</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" />
</Request>'

レスポンス

security-role-0000-0000-000000000000 は、 /app/price-change エンドポイント へのアクセスを許可しません。失敗したリクエストに対するレスポンスには、 リソースへのアクセスを Deny (拒否) する <Decision> 要素が含まれています。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:Response xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <ns3:Result>
        <ns3:Decision>Deny</ns3:Decision>
    </ns3:Result>
</ns3:Response>

PDP - 高度な認可

復習ですが、PDP アクセス制御には3つのレベルがあります。

  • レベル1 :認証アクセス - サイン・インしているすべてのユーザにすべての アクションを許可し、匿名ユーザにはアクションを許可しません
  • レベル2 :基本認可 - 現在ログインしているユーザがアクセスできるリソース と動詞を確認します
  • レベル3 :高度な認可 - XACML に よるきめ細かい制御をします

FIWARE では、スマート・アプリケーション・インフラストラクチャ内の既存の セキュリティ・マイクロサービス (IDM および PEP Proxy) に Authzforce を 追加することで、レベル3のアクセス制御を提供できます。アクセス制御レベル1と2は、 以前のチュートリアル で取り上げてきましたが、Keyrock を単独で使用して、関連する PEP Proxy を使用してもしなくても実行できます。

高度な認可

高度な認可 (Advanced Authorization) は複雑なルールセットを扱うことができます。 権限は、もはや固定のロール、リソース、およびアクションに基づいているだけでなく、 必要に応じて拡張することもできます。

たとえば、ロール XXX のユーザは、HTTP 動詞が GET, PUT, POSTいずれかであれば、YYY で始まる URL にアクセスできます。 そのようなユーザは、彼らがそもそも作成者であることを条件として DELETE を実行することもできます。

チュートリアルのプログラム例の中で私たちは Keyrock の私達の自身の信頼された インスタンスを使用しています。一度ユーザがサインインして access_token を取得すると、access_token はセッションに保存されリクエストに応じてユーザの 詳細を取得するために使われます。Orion Context Broker へのすべてのアクセスは、 PEP Proxy の背後に隠されています。リクエストが Orion に行われるたびに、 access_token がリクエストのヘッダで渡され、PEP Proxy がそのリクエストを 実行するかどうかの決定を処理します。

ユーザがアクセス・トークンを取得

自分自身を識別するためには、すべてのユーザがアクセス・トークンを 取得する必要があります。そのためには、 以前のチュートリアル で説明した OAuth2 アクセス許可のいずれかを使用する必要があります。

ユーザ資格情報フローを使用してログインするには、grant_type=password を指定して Keyrockoauth2/token エンドポイントに POST リクエストを送信します。

9 リクエスト

curl -X POST \
  http://localhost:3005/oauth2/token \
  -H 'Accept: application/json' \
  -H 'Authorization: Basic dHV0b3JpYWwtZGNrci1zaXRlLTAwMDAteHByZXNzd2ViYXBwOnR1dG9yaWFsLWRja3Itc2l0ZS0wMDAwLWNsaWVudHNlY3JldA==' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'username=bob-the-manager@test.com&password=test&grant_type=password'

レスポンス

レスポンスはユーザを識別するために access_token を返します (この場合は Bob マネージャ)

{
    "access_token": "08fef363c429cb34cfff3f56dfe751a8d1890690",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "35a644094b598cb0d720fcb323369a53820a6a44",
    "scope": ["bearer"]
}

ロールとドメインを取得

ユーザがログインしている場合、access_token/user エンドポイントと組み合わせて リソースへのアクセス許可を得るために使用できます。 この例では、特定のリソースに対する Bob の権限を取得します。

19 リクエスト

curl -X GET \
  'http://localhost:3005/user?access_token={{access_token}}&app_id={{app-id}}&authzforce=true'

ここで :

  • {{access-token}} は、ログインしているユーザの現在のアクセス・トークンです (例 : 08fef363c429cb34cfff3f56dfe751a8d1890690)
  • {{app-id}}tutorial-dckr-site-0000-xpresswebapp をリクエストする アプリケーションを保持し、authzforce=trueKeyrock から Authzforce ドメインを取得したいことを示します

レスポンス

レスポンスには、リクエストへの直接アクセスを拒否する authorization_decision 属性を含みますが、追加のリクエストが Authzforce からの決定になるように 追加の情報が含まれています。

以下の例では、使用されたアクセス・トークンはマネージャの Bob に属し、 そのロールと app-id に関連付けられた app_azf_domain が返されます。

{
    "organizations": [],
    "displayName": "",
    "roles": [
        {
            "id": "managers-role-0000-0000-000000000000",
            "name": "Management"
        }
    ],
    "app_id": "tutorial-dckr-site-0000-xpresswebapp",
    "trusted_apps": [],
    "isGravatarEnabled": false,
    "email": "bob-the-manager@test.com",
    "id": "bbbbbbbb-good-0000-0000-000000000000",
    "authorization_decision": "",
    "app_azf_domain": "gQqnLOnIEeiBFQJCrBIBDA",
    "eidas_profile": {},
    "username": "bob"
}

ポリシーをリクエストに適用

Authzforce に決定をリクエストするには、すべての関連情報を含む構造化 リクエストを domains/{domain-id}/pdp エンドポイントに送信する必要があります。 この場合、リクエストのボディには、ユーザが持つロール (managers-role-0000-0000-000000000000)、リクエストされているアプリケーション id (tutorial-dckr-site-0000-xpresswebapp)、リクエストされている HTTP 動詞と リソース (/v2/entities URL に対する POST リクエスト) などの情報が含まれます。

11 リクエスト

curl -X POST \
  http://localhost:8080/authzforce-ce/domains/gQqnLOnIEeiBFQJCrBIBDA/pdp \
  -H 'Content-Type: application/xml' \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">
   <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">managers-role-0000-0000-000000000000</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">tutorial-dckr-site-0000-xpresswebapp</AttributeValue>
      </Attribute>
      <Attribute AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/v2/entities</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
      <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">POST</AttributeValue>
      </Attribute>
   </Attributes>
   <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" />
</Request>'

レスポンス

レスポンスには、リクエストを Permit (許可) または Deny (拒否)するための <Decision> 要素が含まれています。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:Response xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
  xmlns:ns2="http://www.w3.org/2005/Atom"
  xmlns:ns3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
  xmlns:ns4="http://authzforce.github.io/core/xmlns/pdp/6.0"
  xmlns:ns5="http://authzforce.github.io/pap-dao-flat-file/xmlns/properties/3.6">
    <ns3:Result>
        <ns3:Decision>Permit</ns3:Decision>
    </ns3:Result>
</ns3:Response>

高度な認可 - サンプル・コード

プログラム的には、Policy Execution Point は2つの部分から構成されます。 Keyrock に対する OAuth リクエストは、ユーザに関する情報 (割り当てられたロールなど) と、照会されるポリシー・ドメインを取得します。

2番目のリクエストが Authzforce 内の関連ドメイン・エンドポイントに送信され、 Authzforce が判断を下すために必要なすべての情報が提供されます。Authzforce は permit (許可) または deny (拒否) のレスポンスで応答し、 続行するかどうかの決定はその後行うことができます。

function authorizeAdvancedXACML(req, res, next, resource = req.url) {
    const keyrockUserUrl =
        "http://keyrock/user?access_token=" +
        req.session.access_token +
        "&app_id=" +
        clientId +
        "&authzforce=true";

    return oa
        .get(keyrockUserUrl)
        .then(response => {
            const user = JSON.parse(response);
            return azf.policyDomainRequest(
                user.app_azf_domain,
                user.roles,
                resource,
                req.method
            );
        })
        .then(authzforceResponse => {
            res.locals.authorized = authzforceResponse === "Permit";
            return next();
        })
        .catch(error => {
            debug(error);
            res.locals.authorized = false;
            return next();
        });
}

各リクエストを Authzforce に提供するための完全なコードはチュートリアルの Git リポジトリ にあります。提供する実際の情報はビジネス・ユースケースに依存します。 一時的な情報、レコード間の関係などを含むように拡張できます。 非常に単純な例ではロールだけが必要です。

const xml2js = require("xml2js");
const request = require("request");

function policyDomainRequest(domain, roles, resource, action) {
    let body =
        '<?xml version="1.0" encoding="UTF-8"?>\n' +
        '<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="false">\n';
    // Code to create the XML body for the request is omitted
    body = body + "</Request>";

    const options = {
        method: "POST",
        url: "http://authzforceUrl/authzforce-ce/domains/" + domain + "/pdp",
        headers: { "Content-Type": "application/xml" },
        body
    };

    return new Promise((resolve, reject) => {
        request(options, function(error, response, body) {
            let decision;
            xml2js.parseString(
                body,
                { tagNameProcessors: [xml2js.processors.stripPrefix] },
                function(err, jsonRes) {
                    // The decision is found within the /Response/Result[0]/Decision[0] XPath
                    decision = jsonRes.Response.Result[0].Decision[0];
                }
            );
            decision = String(decision);
            return error ? reject(error) : resolve(decision);
        });
    });
}

高度な認可 - PEP Proxy

PEP Proxy 内で高度な認証を適用するには、上記のプログラム例と非常によく似た コードが必要です。Wilma Generic Enablerは、リクエストによって供給される ヘッダからトークンを抽出し、リクエスト行う Keyrock ユーザに関するさらなる 情報を得るために。次に PDP リクエストがAuthzforce に対して行われ、 続行するかどうかが決定されます。

明らかに、スケーラブルなソリューションであれば、不要なリクエストを避けるために、 行われた PDP リクエストとレスポンスに関する情報もキャッシュする必要があります。

PDP - 高度な許可 - 例の実行

レベル3では5つのリソースが確保されています :

  • ドアのロック解除コマンドを送信
  • ring bell コマンドを送信
  • 価格変更エリアへのアクセス
  • オーダー在庫エリアへのアクセス
  • Orion へのアクセス (PEP Proxy の背後)

Eve 盗聴者

Eve はアカウントを持っていますが、アプリケーション内にロールはありません。

Eve は認識されたアカウントを持っているので、完全な認証アクセスを 得ます。これは、自分のアカウントにロールがアタッチされていなくても、 自分がストア・ページを_view_ (表示) できることを意味します。

  • http://localhost:3000から、eve@example.com として、パスワード test でログインします
レベル 3 : 高度な認可アクセス
  • ストア・ページをクリック - ログインしたユーザはそのページを見るための アクセスを許可されますが、Eve にはアクセスを許可するロールがないため、 Orion データを取得するためのアクセスは拒否されます

  • http://localhost:3000 で制限されたアクセス・リンクをクリック - アクセスは拒否されます

  • http://localhost:3000/device/monitor でデバイス・モニタをオープン
    • ドアのロックを解除 - アクセスは拒否されます
    • ベルを鳴らす - アクセスは拒否されます

Bob 地域マネージャ

Bob は、management ロールを持っています

  • http://localhost:3000 から、bob-the-manager@test.com として、 パスワード test でログインします
レベル 3 : 高度な認可アクセス
  • http://localhost:3000 で制限されたアクセス・リンクをクリック - アクセスは許可されます - これは management のみの権限です
  • http://localhost:3000/device/monitor でデバイス・モニタを開きます
    • ドアのロックを解除 - アクセスは拒否されます - これは security のみの許可です
    • ベルを鳴らす - アクセスは許可されます - これは management ユーザに許可されます

Charlie セキュリティ・マネージャ

Charlie は、the security ロールを持っています

  • http://localhost:3000 から、charlie-security@test.com として、 パスワード test でログインします
Level 3: Advanced Authorization Access
  • http://localhost:3000 で制限されたアクセス・リンクをクリック - アクセスは拒否されます - これは management のみの権限です
  • http://localhost:3000/device/monitor でデバイス・モニタを開きます
    • ドアのロックを解除 - アクセスは許可されます - これは security のみの許可です
    • ベルを鳴らす - アクセスが許可されます - これは security ユーザに許可されます

次のステップ

高度な機能を追加することで、アプリケーションに複雑さを加える方法を知りたいですか ?このシリーズの 他のチュートリアルを 読むことで見つけることができます。


License

MIT © 2018-2019 FIWARE Foundation e.V.