selmertsxの素振り日記

ひたすら日々の素振り内容を書き続けるだけの日記

Local環境のアプリケーションに対してAzure ADでOpenID Connectの認証をしてみる (その2)

TL;DR

  • Azure ADでOpenID Connectの認証ができるか確認をした
  • 確認環境は森岡がテスト用に作ったアプリケーション
  • 上記環境はLocal環境で動いていて、Dockerで構成されている
  • lua-resty-openidcを使ってnginxレイヤーだけで認証ができた
  • まだ本番への反映をしていないので、完成度は30%くらい
    • sessionが切れたときに、/login に強制的にredirectさせる方法
    • dockerでない環境での反映手順も考えられていない
  • Azure AD側にアプリケーションを登録しなければ使えないので、ある程度セキュアではなかろうか

Azure ADの設定

Azure AD側の設定は、基本的にAzure AD公式ドキュメントの方法に従う。

  • Azure Potalにサインインする
  • Azure Active Directoryからアプリの登録を行う
  • サインオンURLの設定をする
    • 今回はlocalで確認するので http://127.0.0.1:8080 とした
  • アプリケーションのプロパティから、アプリケーションIDを確認し控えておく
  • 「キー」から鍵を作成して控えておく
  • このアプリケーションにアクセス可能な人をAzure AD上で設定しておく

f:id:selmertsx:20180710140021p:plain

アプリの登録

f:id:selmertsx:20180710140036p:plain

鍵の登録

実装

Docker Build

今回、サクッと確認するためにDockerで環境を構築。 nginxのlua pluginでOIDCができるやつがいたので、こいつを利用させて貰う。

FROM openresty/openresty:1.13.6.2-0-centos
ADD conf.d/app.conf /etc/nginx/conf.d/app.conf
ADD nginx.conf /usr/local/openresty/nginx/conf/nginx.conf
ADD src /usr/local/openresty/nginx/src
RUN opm install zmartzone/lua-resty-openidc
CMD ["/usr/bin/openresty", "-g", "daemon off;"]

openrestyのdocker imageには、opm(openresty package manager)がデフォルトで入っているので、そのopmを使ってlua-resty-openidcをinstallすることができる。

証明書の設定

luasslを利用する際は、lua_ssl_trusted_certificate ディレクティブに証明書の設定をする必要がある。この証明書だけれども、実はopenrestyのdocker imageの中にデフォルトで入っているので、今回はそれを利用する。

➜  pomodoro git:(master) ✗ docker exec -it pomodoro-web /bin/bash
[root@bba9dae7baca /]# ls -al /etc/ssl/certs/
total 8
drwxr-xr-x 2 root root 4096 Apr  2 18:38 .
drwxr-xr-x 5 root root 4096 Apr  2 18:38 ..
lrwxrwxrwx 1 root root   49 Apr  2 18:38 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx 1 root root   55 Apr  2 18:38 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

これをnginxの設定に記載して終了。実際のコードはここ を参照

Luaコードの設定

-- https://github.com/selmertsx/pomodoro/blob/master/docker/nginx/src/test.lua
local opts = {
  redirect_uri_path = "/",
  discovery = os.getenv("DISCOVERY"),
  client_id = os.getenv("CLIENT_ID"),
  client_secret = os.getenv("CLIENT_SECRET"),
}

local res, err = require("resty.openidc").authenticate(opts)

if err then
  ngx.status = 500
  ngx.say(err)
  ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
end

ngx.req.set_header("X-USER", res.id_token.sub)

環境変数の渡し方

discovery, client_id, client_secretはシークレットな情報なので環境変数で渡す。 nginxでは環境変数luaに渡すためには、env directiveを利用する必要がある。

The NGINX environment variable is used internally by nginx and should not be set directly by the user.

公式ドキュメントには上記のように記載されているので、nginx.confの一番上でenv directiveを利用する。

worker_processes  1;
env DISCOVERY;
env CLIENT_ID;
env CLIENT_SECRET;
events {
  worker_connections  1024;
}

なお CLIENT_IDやCLIENT_SECRETはAzure AD設定時に取得したアプリケーションIDや鍵を設定すれば良い。

環境変数DISCOVERYの設定

discovery urlの取得方法については、公式ドキュメントに記載されている通りであるが、少しばかりハマりポイントがあるので解説。ここだけはちゃんと読んでほしい。

  • https://login.microsoftonline.com/{tanent_name}/.well-known/openid-configuration でアクセスし、tanent_idを取得
  • https://login.microsoftonline.com/{tanent_id}/.well-known/openid-configuration の文字列をnginxに設定する

上記設定の理由

ここは興味があれば見るくらいで良い。

まず前提として、Azure ADにおいて、Discoveryは下記2つのフォーマットで取得することができる

  1. https://login.microsoftonline.com/{tanent_name}/.well-known/openid-configuration
  2. https://login.microsoftonline.com/{tanent_id}/.well-known/openid-configuration

lua-resty-openidcを利用する場合、2番のフォーマットでDiscoveryを指定しなければならない。その理由は、lua-resty-openidcの実装上の問題である。上記ライブラリにおいて、openidcの認証は下記のような実装になっている。

-- https://github.com/zmartzone/lua-resty-openidc/blob/master/lib/resty/openidc.lua#L469-L509
      ngx.log(ngx.DEBUG, "response data: "..res.body)
      json, err = openidc_parse_json_response(res)
      if json then
        if string.sub(url, 1, string.len(json['issuer'])) == json['issuer'] then
          openidc_cache_set("discovery", url, cjson.encode(json), exptime or 24 * 60 * 60)
        else
          err = "issuer field in Discovery data does not match URL"
          ngx.log(ngx.ERR, err)
          json = nil
        end
      end

DiscoveryのURLと、discovery urlから返されるissuerのURLの一部が一致しているか見ている。Discoveryから得られるissuerのURLは、https://sts.windows.net/{tanent_id}/ という値になる。そのため、tanent_nameでURLを指定すると一致しないという問題が起きる。よって、Discovery取得用のURLは、tanent_idで指定する必要がある。

認証結果

http://127.0.0.1:8080/test にアクセスすると下記のページにredirectされる

f:id:selmertsx:20180710135840p:plain

認証が終わるとこんな感じ

f:id:selmertsx:20180710135916p:plain

lua-nginx-moduleをdockerで動かす

TL;DR

  • imageの指定方法は、下記のフォーマット
    • openresty/openresty:<openresty-version>-<image-version>-<flavor>
    • flavorとはosのことでcentos, alpine などが入る
    • 今回はこんな感じになった openresty/openresty:1.13.6.2-0-centos
  • 上記方法でイメージを作れば、すぐにluaを実行可能

github.com

設定方法

nginxでluaを実行するために必要な部分のみ抜粋。全体は下記のurlから探してほしい。

https://github.com/selmertsx/pomodoro/blob/29872473c7cbc6c6cbf1fe27bc8d9a9434ae80ba/docker-compose.yml#L43-L52

docker-compose.yml

volumesで自分の手元のnginx設定をcontainerにマウントした。

version: '3'
services:
  nginx:
    build: ./docker/nginx
    container_name: pomodoro-web
    image: pomodoro-web
    volumes:
      - ./docker/nginx/conf.d:/etc/nginx/conf.d
    ports:
      - 8080:80

Dockerfile

手元のnginx設定をaddしている。 この設定ファイルはdocker-composeでmountしているから、開発環境ではいらないかも。

FROM openresty/openresty:1.13.6.2-0-centos
ADD conf.d/app.conf /etc/nginx/conf.d/app.conf
CMD ["/usr/bin/openresty", "-g", "daemon off;"]

nginx app.conf

普通に hello world

server {
  listen 80;
  server_name localhost; 
  keepalive_timeout 5;
  location /hellolua {
    content_by_lua '
        ngx.header["Content-Type"] = "text/plain";
        ngx.say("hello world");
    ';
  }
}

実行確認

➜  pomodoro git:(master) ✗ curl http://127.0.0.1:8080/hellolua
hello world

ということで、問題なく動作していることを確認したぞ!!

Local環境のアプリケーションに対してAzure ADでOpenID Connectの認証をしてみる (その1)

Motivation

Azure ADをIDaaSとして、社内サービスと連携したい。 弊社の社内サービスはPHPJavaRubyと多種多様な言語で書かれており、 またインフラもGCP,AWSと利用されているので、 それらすべてで動くようにnginxレイヤーでIDaaS連携をするようにする必要がある。 ということで、今回はnginxでIDaaS連携ができるライブラリを調査することにする。

AWS のみならば、ALBレイヤーでAzure ADと連携することが可能である。 社内サービスがAWSのみであれば、これを利用するのが最も楽だと思う。

Application Load Balancer 組み込み認証によりログインを簡略化 | Amazon Web Services ブログ

OpenID ConnectとSAML

Azure ADにおいてフェデレーションアクセスをする際のプロトコルとして、OpenID ConnectとSAMLが存在する。 SAMLはIdP側だけでなくSP側もメタデータの登録などが必要であり、設定コストが非常に高い。 そのためOpenID Connectで、求める水準のID管理が出来るのであれば、それにこしたことはない。 なので、一旦OpenID Connectでどこまでできるのか検証を進めていく。

用語の確認

OpenID Connect

  • RP (Relying Party) : SSO対象のアプリケーション
  • OP (OpenID Provider ) : IDの認証を行う機能を有するサーバー

その他、OpenID Connectに関する基礎的な知識は、下記URLを参照。

OpenID Connectまとめ - selmertsxの素振り日記

SAML (Security Assertion Markup Language)

  • SP (Service Provider) : SSO対象のアプリケーション. OpenID Connectで言うRP
  • IdP (Identity Provider) : IDの認証を行うサーバー. OpenID Connetで言うOP

nginx library

github.com

OpenID ConnectのRPに使うための nginx lua library. OpenID Connect DiscoveryとAuthorization code flowを使って、OPとユーザー認証を行う。 セッションはブラウザのcookieか、redis, memcacheで持つ。

使い方

local opts = {
  redirect_uri_path ="",
  discovery = ""
  -- ... その他args
}

local res, err = require("resty.openidc").authenticate(opts)

if err then
  ngx.status = 500
  ngx.say(err)
  ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
end

こんな感じ。opsに必要なパラメータを入れた後、require("resty.openidc").authenticate(opts) で認証を実行する。 どんなパラメータが必要なのかはAzure ADと連携するときにでも諸々確認していく

現状の懸念点

  • OpenID Connectで認証した場合、IDaaSでは認証はできるが認可はできないのではないだろうか

www.slideshare.net

OpenID Connectまとめ

概要

OpenID Connectは認証用のプロトコルである。 認可フローはOAuth 2.0そのままで、属性情報も渡せるようになる。 OpenID Connectを理解する上で、必要な用語は下記の通りある。

認証フロー

  • Authorization Code Flow
  • Implicit Flow

認証フローはHTTP requestのパラメータに追加することで指定することができる。

HTTP/1.1 302 Found
Location: https://op.example.domain/authorize?
response_type=code # <== ここ!!!
&scope=openid%20profile%20email
&client_id=XXXXXX
&state=abcdefg123
&redirect_uri=https%3A%2F%2Frp.example.domain%2Fcallback

Authorization Code Flow

認証手順

  • Client は必要なパラメータを含む Authentication Request を用意する.
  • Client は Authorization Server にリクエストを送信する.
  • Authorization Server は End-User を Authenticate する.
  • Authorization Server は End-User の Consent/Authorization を得る.
  • Authorization Server は Authorization Code を添えて End-User を Client に戻す.
  • Client は Token Endpoint へ Authorization Code を送信する.
  • Client は ID Token と Access Token をレスポンスボディに含むレスポンスを受け取る.
  • Client は ID Token を検証し, End-User の Subject Identifier を取得する.

ResourceProviderからUserInfoにアクセスするのが Implicit Flowとの大きな違い。

Implicit Flow

認証手順

  • Client は必要なパラメータを含む Authentication Request を用意する.
  • Client は Authorization Server にリクエストを送信する.
  • Authorization Server は End-User を Authenticate する.
  • Authorization Server は End-User の Consent/Authorization を得る.
  • Authorization Server は ID Token, および要求があれば Access Token を添えて End-User を Client に戻す.
  • Client は ID Token を検証し, End-User の Subject Identifier を取得する.

Authorization Code Flowとの大きな違いは下記の通り

  • ID TokenとAccess TokenがAuthorizationエンドポイントから返却される
  • ID Tokenの受け渡しはブラウザ上で動作するClientで行う
  • OpenID ProviderとRelying Partyの間で通信できない環境でも採用可能

http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#ImplicitFlowAuth

Implicit Flow は主にスクリプト言語を用いて実装されブラウザ上で動作する Client によって使用される. Access Token と ID Token は, Client に直接返却され, その Access Token と ID Token は, End-User と End-User の User Agent にアクセスするアプリケーションに露出する可能性がある. Authorization Server は Client Authentication を行わない.

ということで、SPAでやってるサービスなら、Implicit Flowを使う。

所感

OpenID Connectはユーザーに認証をさせる。 SAMLはサービスとIdPに認証をさせる。

OpenID Connectは、登録されるサービスの信頼性をIdPが確認しない。 自由に登録できるという点はメリットでもあり、デメリットでもある。

SAMLは登録するサービスをIdP側が完全に把握できる。 設定コストが高いという点ではデメリットでもある。

僕の読んだ資料

G SuiteをAWSのIDaaSとして使ってみたけど個人的にはイマイチだった

概要

G Suiteには Cloud Identity という IDaaSのサービスがあります。 G Suiteをすでに利用しているなら、こいつをIDaaSとして使えれば低コストでいけます。 なので、ちょっと試してみました。僕の認識不足な部分でイマイチな結論だしている部分があったらコメント貰えると嬉しいです。

support.google.com

TL; DR

  • 基本的には下記資料の手順に従って設定をした
  • https://aws.amazon.com/jp/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-apps/
  • 設定のためには、Directory APIの設定ができる権限が必要
  • ユーザー情報の一つの属性として設定する必要がある
    • 権限は個人単位で設定しなければならない
  • 結論としては利用しない
    • APIで構築することに寄せるか、consoleでの設定に寄せるかしてほしい
    • 権限管理がグループ・組織ではなく、個人に紐づくのはびみょう

設定手順について

https://aws.amazon.com/jp/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-apps/

基本的には上の手順でやってけば良い。現在はG Suite側にAWSのコネクタがあるので、それを使えばもっと手間が省ける。 ざっくりいうと、下記のような内容になる。ここでは、細かい作業内容を詳細に記載しない。

  • G Suite側にてIdpの証明書を発行する
  • AWS側にてG SuiteのIdpを登録する
  • AWS側にて G Suiteからフェデレーションアクセスする際のロールを作る
  • G Suite側にてフェデレーションアクセスする際のロールを指定する custom schemaを作成する
  • G Suite側にてService Providerの設定を行う

SPにアクセスする方法

f:id:selmertsx:20180613150820p:plain

これはめっちゃ便利。みんなchrome使ってるだろうし、IDaaS専用のページから遷移しなくてよいの良い。

微妙だったところ

設定にAPIが必要である

f:id:selmertsx:20180613150837p:plain ※ 面倒だったので、webコンソール上から実行。

{
  "customSchemas": {
    "SSO": {
      "role": [
        {
          "value": "arn:aws:iam::xxx:role/TestGsuiteReadOnlyRole,arn:aws:iam::xxx:saml-provider/TestGoogleApps",
          "customType": "TestGsuiteReadOnlyRole"
        }
      ]
    }
  }
}
{
  "fields":
    [
      {
          "fieldName": "role",
          "fieldType": "STRING",
          "readAccessType": "ADMINS_AND_SELF",
          "multiValued": true
      }
  ],
  "schemaName": "SSO"
}
  • SPとの連携において、SP側が求めるパラメータを渡すためには、APIを使って G Suite側のユーザー情報を拡張しなければならない。
  • 影響範囲を考えるとstaging環境での検証が必須
  • 事故が起きたときの被害が大きい

AWSのIDaaSとしての権限管理はユーザー単位でしかできない

f:id:selmertsx:20180613151123p:plain

{
  "customSchemas": {
    "SSO": {
      "role": [
        {
          "value": "arn:aws:iam::xxx:role/TestGsuiteReadOnlyRole,arn:aws:iam::xxx:saml-provider/TestGoogleApps",
          "customType": "TestGsuiteReadOnlyRole"
        }
      ]
    }
  }
}

こんな感じでAWSとの連携においては、ロールの設定はユーザー個人ごとに行う必要がある。人の異動に応じて権限を変えたいので、個人ではなくてグループ・所属に権限をもたせたい。それをやるためには、権限管理用のサービス作らないといけない。

Rubyで型チェックをしてくれるsteepを試してみた

TL;DR

使い方

class Person
  # @dynamic name, contacts
  attr_reader :name, :contacts

  def initialize(name:)
    @name = name
    @contacts = []
  end

  def guess_country()
    contacts.map do |contact|
      case contact
      when Phone
        contact.country
      end
    end.compact.first
  end
end

class Phone
  # @dynamic country, number
  attr_reader :country, :number

  def initialize(country:, number:)
    @country = country
    @number = number
  end

  def ==(other)
    if other.is_a?(Phone)
      other.country == country && other.number == number
    end
  end

  def hash
    self.class.hash ^ country.hash ^ number.hash
  end
end
# 型定義ファイル
class Person
  @name: String
  @contacts: Array<Phone>
  def initialize: (name: String) -> any
  def name: -> String
  def contacts: -> Array<Phone>
  def guess_country: -> (String | nil)
end

class Phone
  @country: String
  @number: String
  def initialize: (country: String, number: String) -> any
  def country: -> String
  def number: -> String
end
bundle exec steep check -I test.rbi test.rb
# 何も問題がなければ何も出ない

問題がある場合

phone = Phone.new(country: 'Japan', number: 1)

こんな感じでstring型が期待される場所に、integerを渡してみた.

➜  steep git:(master) ✗ bundle exec steep check -I test.rbi test.rb
test.rb:40:44: ArgumentTypeMismatch: receiver=::Phone.class constructor, expected=::String, actual=::Integer (1)

という訳で、string型が求められてる場所にintegerを渡すと怒ってくれる。

忘れがちな設定

@dynamic コメント

class Person
  # @dynamic name, contacts
  attr_reader :name, :contacts

attr_readerなど、methodとして定義しないattributesを扱う場合、 # @dynamic attribute_name で指定しなければならない。 これを忘れると、下記のようにmethod missingのエラーが出る。

➜  steep git:(master) ✗ bundle exec steep check -I test.rbi test.rb
test.rb:1:0: MethodDefinitionMissing: module=::Person, method=name (class Person)
test.rb:1:0: MethodDefinitionMissing: module=::Person, method=contacts (class Person)

所感

  • 普通に自分の個人プロダクトでは採用して良いのではなかろうかというレベルに来てる。
  • Railsくらいの規模のコードで問題なく使えるか検証したい
  • 大きなライブラリも導入してくれると、コードを読むときに助かる気持ち

【雑メモ】AWS CloudTrailメモ

  1. CloudTrailとは

AWSのユーザー、ロールによって実行されたアクションを記録するもの。 AWSマネジメントコンソール、AWS CLIAWS SDKで実行された全てのアクションが記録される。 ログはS3に記録され、SSEを使用して暗号化される。 記録するデータには大きく分けて、管理イベントとデータイベントがある。 データイベントについては、記録するか否か選ぶことができる。

アクセスから15分後に、ログファイルは配信される。これは変更することも可能である。ログファイルは監査に使われるため、通常の権限では変更できないものでなければならない。ログファイルは、splunk等の外部サービスとも連携することが可能である。CloudTrailでは全てのAWSサービスが、対応している訳ではない。

管理イベント

  • セキュリティグループの設定 (例: IAM AttachRolePolicy API オペレーション).
  • デバイスの登録 (例: Amazon EC2 CreateDefaultVpc API オペレーション).
  • データをルーティングするルールの設定 (例: Amazon EC2 CreateSubnet API オペレーション).
  • ログ記録の設定 (例: AWS CloudTrail CreateTrail API オペレーション).

データイベント

  • Amazon S3 オブジェクトレベルの API アクティビティ (例: GetObject、DeleteObject、PutObject API オペレーション).
  • AWS Lambda 関数の実行アクティビティ (Invoke API).

CloudWatch Logsとの連携

ログデータのモニタリングに使えるやつ。CloudTrailで取得したデータを、ここに突っ込むのもあり。ルールを指定して、それに合致するLogが来たらアラート飛ばすなども可能。

CloudTrailとリージョン

基本的に、AWSパーティション内の全てのリージョンで監査する。 (ap-northeast01aとかそういうことかな?) あまり使用しないリージョンでリソースされたときなどの、異常なアクティビティを検知できるから。1つのリージョンに対してMAX5つのtrail logを残すことが可能。

グローバルサービスイベントについて

AWS Identity and Access Management (IAM)、AWS STSAmazon CloudFront、Route 53などの、複数のリージョンにまたがって存在するリソースのイベント。これらは、US East (N. Virginia) に記録される。設定を失敗すると、重複して送られてしまうこともあるのでよく確認すること。

https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail-by-using-the-aws-cli.html#cloudtrail-create-and-update-a-trail-by-using-the-aws-cli-examples-gses

CloudTrailで取得できるログについて

AccountID_CloudTrail_RegionName_YYYYMMDDTHHmmZ_UniqueString.FileNameFormat
111122223333_CloudTrail_us-east-2_20150801T0210Z_Mu0KsOhtH1ar15ZZ.json.gz
  • UniqueStringは自動で生成されそうな気配 (未確認)

実際のログについて

{"Records": [{
    "eventVersion": "1.0",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "EX_PRINCIPAL_ID",
        "arn": "arn:aws:iam::123456789012:user/Alice",
        "accessKeyId": "EXAMPLE_KEY_ID",
        "accountId": "123456789012",
        "userName": "Alice"
    },
    "eventTime": "2014-03-06T21:22:54Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "StartInstances",
    "awsRegion": "us-east-2",
    "sourceIPAddress": "205.251.233.176",
    "userAgent": "ec2-api-tools 1.6.12.2",
    "requestParameters": {"instancesSet": {"items": [{"instanceId": "i-ebeaf9e2"}]}},
    "responseElements": {"instancesSet": {"items": [{
        "instanceId": "i-ebeaf9e2",
        "currentState": {
            "code": 0,
            "name": "pending"
        },
        "previousState": {
            "code": 80,
            "name": "stopped"
        }
    }]}}
}]}

その他メモ

https://digitalforensic.jp/2011/11/10/column182/