Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

PlayStationでパスキーを使う(実機編)

$
0
0
こんにちは、富士榮です。

前回はPCブラウザでPlayStationネットワークへのログインをする際にパスキーを使う話をしましたが、今回は実機が触れる環境があるので実機でも触ってみましょう。

結果、期待していた本体側でHybridのQRが出て、という形ではなくデバイスフロー+モバイル側でパスキーログインというのが答えでした。
ただし、本体側でパスキー設定を有効化することもできるようなメニューができている点が新しいファームウェアでの対応ポイントっぽいです。

サインイン

本体でPlayStationネットワークへサインインするメニューを立ち上げると、このような画面が出ます。これはパスキーをサポートする前と何も変わりません。よくあるデバイスフロー(もしくはその代替で独自で作った仕組み)でのログインです。

ちなみに「手動でサインインする」を開くと通常通りパスワードでログインする画面は出てきてしまいますがパスキーが有効な状態だとどう頑張ってもログインはできません。


ですので先ほどのQRコードを読み込んでスマホでパスキーを使ってログインする必要があります。


うまくログインできると本体とリンクされて本体側でのサインイン処理が進みます。


本体のセキュリティー設定を見るとちゃんとパスキーが有効になっていることがわかります。



本体でパスキーの登録を行う

では、パスキーが無効な状態で先ほどのセキュリティー設定の画面を開いて、パスキーの生成を本体で行うとどうなるのでしょうか?
ご想像の通りQRコードが出てきます。

こちらを読み取ってスマホ側でパスキー登録を行う、という流れです。






こんな感じです。
せっかくPlayStationにはUSBのコネクタがあるのでYubikeyを使えるとかだと面白かったのですが、、流石にそれはなかったです。

ニンテンドーアカウントでもパスキーが使えるようになっていますし、ゲームコンソールなどのパスワード入力が難しいデバイスのログインもどんどん進化していっていますね。
Switchが欲しくなってきました。





パスキーでログインを実装する(検証編)

$
0
0

こんにちは、富士榮です。

前回の続きです。前回はログイン処理の前段部分まで実装できたので今回はcredential.get()の結果の検証を行います。

その前に、これまでのポストはこちらです。


検証の大きな流れは、以下の通りです。
  • challengeの検証
  • originの検証
  • credentialIdをキーに保存済みの公開鍵をDBから取得
  • verificationDataの生成
  • 公開鍵とsignatureを使ってverificationDataの署名を検証
と、例によってCBORのデコードやバイナリの切り出し、公開鍵の変換(DER→COSE-Key)など本質的ではないところの面倒臭い処理があるので生で実装するのはやめました。

結論はsimplewebauthnのライブラリを使うことになるのですが、その前にざっくりやるべき処理だけ理解しておきたいと思います。(署名検証部分)

  • 鍵の変換
    • パスキー登録の時にレスポンスから取得できるPublicKeyはDER形式なのでcoseに変換する必要があります
    • 変換した鍵の中身を使って以下のBufferを連結して検証用の鍵を作ります
      • 0x04
      • 鍵のx
      • 鍵のy
  • VerificationData(検証対象とするデータ)の生成
    • 以下のBufferを連結して検証対象のデータを生成します
      • 0x00
      • rpIdHash(登録時にも使ったrpIdの検証用のHashと同じ値)
      • clientDataHash(clientDataJSONのSHA256ハッシュ値)
      • credentialId
      • publicKey
結構面倒くさいです。

ということでsimplaewebauthnのライブラリを使いました。
// 検証
constresult=awaitsimpleWebAuthn.verifyAuthenticationResponse({
response:req.body,
expectedChallenge:req.session.challenge,
expectedOrigin:origin,
expectedRPID:req.hostname,
authenticator:authenticator
});

超簡単です。
それぞれパラメータを解説していきます。
  • response
    • nagivator.credential.get()の結果取得できるpublicKeyCredentialをtoJSON()したオブジェクトをそのまま渡します
  • expectedChallenge
    • sessionに保存してあるchallengeを取り出してセットします
  • expectedOrigin
    • アクセスしているサイトのoriginをセットします。以前解説した通りngrokを使っている関係でschemeは工夫しています
// originの生成
constscheme=req.hostname!=='localhost'?"https":req.protocol;
constorigin=url.format({
protocol:scheme,
host:req.get('host')
});
  • expectedRPID
    • ホスト名をつかっています
  • authenticator
    • credentialIdをキーにデータベースを検索し取得した公開鍵と署名回数のデータを含むオブジェクトを生成します(JSONBinに保存しているのでレスポンスの中に公開鍵、署名回数が含まれます)
// authenticator
constauthenticator= {
credentialPublicKey:base64url.toBuffer(JSONBinResponse.publicKey),
credentialID:base64url.toBuffer(credentailId),
counter:JSONBinResponse.signCount
};

これでおしまいです。
検証結果(verified)がtrue/falseで返ってくるので認証OK/NGで処理を振り分けましょう。また、署名回数が前回よりも増えていることの確認をしておくことで認証器の偽造にも対応できます。(MacOSのTouchIDの署名回数は0のままなので署名回数の検証はできません)
if(result.verified) {
// 検証成功
// 検証回数が増えているかどうか(0の場合以外)
if(result.authenticationInfo.newCounter!==0) {
if(result.authenticationInfo.newCounter<=JSONBinResponse.signCount){
console.log("error signCount is not increased");
}
}
// UVが行われているかどうか
if(!result.authenticationInfo.userVerified) {
console.log("user was not verified");
}

こんな感じで認証結果が表示できるように作りました。


と、ここで疑問が湧いてきます。
対象ユーザが正しいかどうかの検証ってしなくていいの?ログイン時にパスワードはもちろんユーザ名も入れてないけど、って話です。
今回の実装ではResidentKeyで認証器側でユーザ情報を持っている前提で組んでいるので、そうではない環境を想定するとユーザ名を入力させて認証はパスキー、という動線も作らないといけません。また、Credential IDだけを使って公開鍵をDBから取得していますが、ちゃんとユーザハンドルとDB内にCredential IDと紐付けて保存されているユーザIDが一致していることの確認をしないといけません。
ということで公開鍵をユーザDBから取得するところのロジックはこんな感じで実装していきます。
}
// credentialIdをキーにPublicKeyとCounterを取得する
// userHandleが一致していることを検証する
exports.getPublicKey=asyncfunction(credentialId, userHandle) {
// JSONBin用のヘッダ
constheaders=newHeaders({
"X-Master-Key":process.env.JSONBIN_MASTER_KEY,
"Content-Type":"application/json"
});
// JSONBinのユーザCollectionからユーザbinのidを取得する
constcollectionUrl=newURL(`${process.env.JSONBIN_BASEURL}/c/${process.env.JSONBIN_PASSKEYCOLLECTION_ID}/bins`);
constcollectionResponse=awaitfetch(collectionUrl, {
headers:headers
});
constpassKeyCollection=awaitcollectionResponse.json();
constpassKeyBin=passKeyCollection.find(i=>i.snippetMeta.name===credentialId);
if(typeofpassKeyBin==="undefined"){
console.log("passKey not found");
return {
result:false,
error:"passKey not found"
}
}else{
// 当該パスキーのBin idからBinの中身を読み出す
constpassKeyBinUrl=newURL(`${process.env.JSONBIN_BASEURL}/b/${passKeyBin.record}`);
constpassKeyBinResponse=awaitfetch(passKeyBinUrl, {
headers:headers
});
constpassKeyJson=awaitpassKeyBinResponse.json();
console.log(passKeyJson);
// ユーザIDが正しいか検証
console.log("userhandle to be compared: "+userHandle);
console.log("expected userhandle : "+passKeyJson.record.userId);
if(userHandle!==passKeyJson.record.userId) {
// ユーザ名が異なる
return {
result:false,
error: "different user handle"
}
} else {
// ユーザ名一致
return {
result:true,
username:passKeyJson.record.username,
publicKey:passKeyJson.record.publicKey,
signCount:passKeyJson.record.signCount
}
}
}
}

まあ、もちろん前提として本来は登録時にCredential IDが重複していないことをチェック、かつユーザIDとの紐づけた上で登録する、というロジックを入れておかないと安全にはならないのでプロダクションで実装する人は注意しましょう。

雑ではありますが一通りパスキーの実装が理解できたので、そろそろ元々のOpenID Provider作りを再開していこうかと思います。



なぜSAMLの脆弱性は今でも報告されるのか。そしてOIDCやVCは大丈夫なのか

$
0
0

こんにちは、富士榮です。

故Craig Burtonが”SAML is Dead”という名言を放ってから永らく経つわけですが、まだまだ現役のSAMLには今でもたまに脆弱性のレポートが出てきます。

* SAML is Dead


昨日もSilver SAML Attackに関するレポートが出ていました。

(図は記事より)

非常にざっくり要約すると、以下のようなことが書かれています。

  • 例としてEntra IDを挙げている
  • Entra IDではSAML Responseへの署名を行う秘密鍵として外部で生成した鍵を利用することができる(BYOK)
  • この鍵が漏洩するなどして不正に利用されるとSAML Responseの偽造ができてしまう
  • 署名に使う鍵はIDシステムの内部で発行したものを使った方が良い
当たり前じゃん。秘密鍵が奪われているんだから。

と言いつつ、何でこう言うことが起きるのかをちゃんと見ていきたいと思います。

脆弱性の原因

SAMLに限らず、ではありますがこの手の仕組みの基本は「デジタル署名を施したデータ(SAML AssertionやOpenID Connectにおけるid_tokenなど)」をIdentity ProviderからRelying Partyからの要求等に応じて送出する、という仕組みになっています。
こうなってくると当然のことながらデジタル署名を確実に実施・検証する、そして先日から順番に読んでいるOAuth2.0 Security Best Current Practiceにも要所要所でててくる、送信元・送信先をいかに限定するか、やり取りの過程の中でCSRFなど攻撃者によるインジェクションをいかにして防ぐか、などがポイントになってきます。
  • 署名・検証の不備を防ぐ
  • 通信過程における攻撃者の関与を防ぐ
後者についてはOAuth2.0 Security Best Current Practiceで見ていくとして、今回は先のSAMLの件もあるのでデジタル署名について見ていきたいと思います。

デジタル署名の前提

デジタル署名を安全に行うための前提は言うまでもなく署名に使う鍵を安全に管理すること、につきます(もちろんアルゴリズムの安全性の話は言うまでもありません)。
今回挙げたケースは鍵を適切に管理できない状態が起きると危ないですよ、というレポートなので、改めて秘密鍵の管理の重要性を説いています。
(もちろん、安全に管理してくださいね、と言ったところで安全に管理できない人たちが多いのは理解していますが、管理方法について深掘りするのはここでは避けます)

なお、今回は鍵管理の話にフォーカスが置かれていましたが、実際の脆弱性はデジタル署名する対象となるデータの生成に依存することが多いと思います。いわゆる「正規化」の問題です。

実際過去に当ブログでも紹介したDuo SecurityのレポートはSAML Assertionを生成する際のXMLの正規化がポイントでした。

正規化の問題

SAMLにおけるXMLは非常に柔軟なデータ表現である一方で「どうやって同一性を担保するか」という問題を抱えています。
例を挙げると、
  • 空白値のトリミング
    • <attribute name="email">test@example.jp</attribute>
    • <attribute name="email"> test@example.jp </attribute>
    • を同一のものとして扱うか
  • コメントの取り扱い
    • <!-- これはコメントです -->
    • <attribute name="email">test@example.jp</attribute>
    • <attribute name="email">test@example.jp</attribute>
    • を同一のものとして扱うか

    と言う問題です。
    これらを解決するために行われるのが「正規化」です。

    XMLの正規化はW3CのCanonical XML Version 2.0で定義されています。

    実際に正規化をする際はこの仕様に従いXMLを処理していくことになるのですが、この過程においてバグが混入することがある、というのが問題の原因になっています。
    実際、先に挙げたDuoのレポートでは値の間にコメントがあった場合の処理に問題があり、別のユーザで認証され生成されたSAML Assertionを使って別のユーザになりすますことができてしまう、というものでした。


    OIDCやVCではどうなのか?

    こう考えるとJSONを使うOpenID Connectや、JSONやJSON-LDを使うVerifiable Credentialsはどうなのか?という疑問が湧いてきます。

    まずOpenID Connectですが署名付きJSONトークンにはRFC7515 JWS(JSON Web Signature)を使っています。

    崎村さんが経緯をブログで紹介されていますが、SAMLの正規化との戦いの経験から「JWSでは正規化を行わない」のがポイントの一つになっています。

    Verifiable Credentialsについてはどうなのか、というとIETFのSD-JWT VCをパターンではOpenID Connectと同じくJWSなので正規化は行いません。
    しかしながらW3C VCはJSON-LDも許容するのでこちらは考えないといけません。JSON-LDはRDF(Resource Description Framework)に基づくLinked Dataを表現するフォーマットですので、正規化をするには、
    を使っていく必要があります。
    しかしながらこの正規化で使われるアルゴリズムであるUniversal RDF Dataset Normalization Algorithm 2015(URDNA-2015)をJSON-LDに適用する際の注意点についてレポートが上がっていたりしますので、実装者はかなり気を遣う必要がります。
    実際、昨年のIIWでもJSON-LDのプロパティ名を変えても署名が崩れないというデモ(Linked Dataの性質を考えると当然の動きではありましたが)もありましたが、VCとして使うにはこのようなことが起きないように注意深くデータ構造を設計する必要があります。

    しかし、この辺りの議論を見ているとJWSが「正規化を行わない」という判断をしたのは非常に重要なことだったことがわかりますね。


    OAuth2.0 Security Best Current Practiceを読んでみる(6)

    $
    0
    0

     こんにちは、富士榮です。

    すこし空きましたがこちらも続けていきます。

    引き続き攻撃パターンと緩和策です。前回はリソースサーバでのアクセストークンの漏洩まで行きましたので続き10個目/18個の盗まれたアクセストークンの悪用から行きたいと思います。


    攻撃パターンと緩和策

    • 盗まれたアクセストークンの悪用
      • これはすでに手遅れ?そもそも攻撃なのか?という感じもしますが、万一アクセストークンが盗まれてしまったとしても被害を最小限に食い止める努力は必要です
      • 基本は送信者制限(Sender Constraint Token)と対象者制限(Audience Restriction)をすべきであるっていう話です
      • 送信者制限(Sender Constraint Token)はその名前の通り、特定の送信者から送信されたアクセストークンのみをリソースサーバが受け付けるようにする、ということです。これはいわゆるべアラ(Bearer)トークンとは対称となる概念ですね
        • 参考)Bearer Tokenとは?
        • 方式としてはmTLS(RFC8705)とDPoP(RFC9449)があります
        • どちらの方式にしても鍵を使ったトークンとのバインディングをするので当たり前ですが秘密鍵の保護は大切です
      • 対象者制限(Audience Restriction)もその名前の通り、特定のリソースサーバでのみアクセストークンが利用できるように制限を行います
        • こちらもアクセストークンが万一漏洩したとしても影響範囲を最小化するための対策です
        • 対象となるリソースサーバを表現するためにはURLなどを利用し、アクセストークン要求時のURLと実際のリソースサーバのURLの値が異なることを検知することによりフィッシング等で作成されたアクセストークンが利用されることを防ぎます
        • リソースを指定するにはRFC8707のresourceパラメータを使ったり、scopeにリソースに関する情報を埋め込むことも可能です
        • そしてこちらもmTLS(RFC8705)による対策も有効です
        • なお、対象者制限付きのアクセストークンを使うと、リソースサーバ単位で特化したアクセストークンを生成することができるので、機能的にもプライバシーの面でもメリットがあります。
      • なお、追加の議論として認可サーバがアクセストークンをどこであれば安全に利用できるのか?という情報を提供することもできますが注意しなければならないことが指摘されています
        • 一つはメタデータで公開する方法ですが、既知のリソースサーバの情報を公開してしまうことになりますし、メタデータの標準ではありません
        • もう一つはトークンレスポンスの中でリソースサーバのURIを合わせて送信するパターンがありますが、正規のリソースサーバへのレスポンスならそれでいいですが、偽造されたリソースサーバへ正規のリソースサーバのURIを送っても何の検証も期待できない面で微妙です
    • オープンリダイレクト
      • クライアント、認可サーバの両方の構成要素がオープンリダイレクトを引き起こしてしまう可能性があるので注意が必要です
      • クライアントがアクセス元となっている画面やページを記憶しておいてトークン取得後にコールバックURIから元のページへ戻す、という実装は一般的ですが、このリダイレクト機能の実装を行う際にオープンリダイレクトを許可してしまう実装にならないように注意する必要があります
      • 認可サーバは仕組み上リダイレクトを行うので、こちらも実装する上でオープンリダイレクトにならないように注意が必要です
      • 基本的にはRFC6749で正しいredirect_uriのみを受け付けてオープンリダイレクトを行わないことがMUSTとして規定されていますが、正しいredirect_uriを使った攻撃パターンも存在するので十分に注意が必要です
      • 例えば、動的クライアント登録を行う際の攻撃パターンとしてこのようなものが紹介されています
        • 無効なスコープを指定するなどしてフィッシングサイト等にリダイレクトさせるように誘導(エラーの際にどこに戻すのか?が結構重要なポイントになりますね。変なリクエストが来たからと言って指定されたredirect_uriに戻しちゃうとこう言うことが起きるのかと)
        • 有効な認可リクエストを送信、この際にredirect_uriは攻撃者の制御の元にあるURLを利用する。ユーザ認証の後、属性提供同意画面でユーザが拒否をしたとしてもredirect_uri(フィッシングサイト)へ戻される
        • この状態でprompt=noneでサイレントログインをするとフィッシングサイトへリダイレクトされてしまう
      • 難しい問題だと思いますが、ユーザをリダイレクトする前にちゃんとユーザを認証する、redirect_uriをちゃんと信頼できるかどうか検証する、など考えないといけません
    • 307 リダイレクト
      • 通常のリダイレクトはGETリクエストのみについてリダイレクトする302を使うと思いますが、代わりに307を使ってしまうとPOSTリクエストについてもリダイレクトしてしまいます。
      • 通常認可サーバに対するリクエストを受けるとユーザは認証行為を行うわけですが、その際クレデンシャル情報をPOSTすることになることが多いと思います。ここで307を使ってしまうと意図せずにクレデンシャル情報が別のサーバへ転送されてしまうので307を使うべきではありません

    まだまだ続きます(長い)。
    とは言え、実装していかないとここの対策についてイメージがわかないと思うので、一通り眺めたら実装にしつつ確認していきたいと思います。

    VC WalletのVC発行エンドポイントへの対応を見てみる

    $
    0
    0

    こんにちは、富士榮です。

    日本でも日本以外でもVerifiable Credentialsが流行っていて(私の周りだけ?)、色々な事業者がIssuanceのデモやウォレットのデモを公開しているので定期的に巡回をしているのですが、先日ようやくImplementer's Draft 1に向けて第一歩を踏み出したOpenID for Verifiable Credential IssuanceのBreaking Changesに対応はまだまだ進んでいないのが実情だなぁ、というあたりの雑談です。

    今回手元にあったのでウォレットとVC発行サイトとして、

    • Auth0 Lab
    • walt.id
    を見てみたいと思います。

    Credential発行時のカスタムスキームの変更

    その前に、OpenID for Verifiable Credential Issuanceのdraft 9とdraft 10の間で何が起きたのかみていこうと思います。(ちなみにImplementer's draft候補はdraft 13です)
    先日も紹介したchange logを見るとこうあります。

    -10

    • introduced differentiation between Credential Issuer and Authorization Server
    • relaxed Client identification requirements for Pre-Authorized Code Grant Type
    • renamed issuance initiation endpoint to Credential Offer Endpoint
    • added grants structure to Credential offer
    issuance initialtion endpointをCredential Offer Endpointにリネームしたことがわかります。具体的にどうなったのかを今更ながら見てみましょう。
    こちらがdraft 9のclient metadataに関する記載です。

    11.1. Client Metadata

    This specification defines the following new Client Metadata parameter in addition to [RFC7591] for Wallets acting as OAuth client:

    • initiate_issuance_endpoint: OPTIONAL. URL of the issuance initation endpoint of a Wallet.

    If the Credential Issuer is unable to perform discovery of the Issuance Initiation Endpoint URL, the following claimed URL is used: openid-initiate-issuance://.

    そしてこちらがdraft 10の当該箇所です。

    10.1. Client Metadata

    This specification defines the following new Client Metadata parameter in addition to [RFC7591] for Wallets acting as OAuth client:

    • credential_offer_endpoint: OPTIONAL. URL of the issuance initation endpoint of a Wallet.

    If the Credential Issuer is unable to perform discovery of the Credential Offer Endpoint URL, the following claimed URL is used: openid-credential-offer://.


    openid-initiate-issuanceからopenid-credential-offerに変わっていますね。ウォレットはこのカスタムスキームを見て起動してくるのでここが変わると起動できません。
    と言うことでAuth0 labsとwalt.idを見てみましょう。

    Auth0 labs

    以前紹介しましたね。Credential発行時のQRコードをこの辺りのサイトで読み込ませてみて、Auth0がどのようなURLスキームを期待しているのか見てみましょう。

    期待しているのは
    openid-initiate-issuance://?issuer=https%3A%2F%2Fっxxxx.auth0lab.com&credential_type=Auth0LabMemberCredential
    でした。OID4VCIのdraft 9までの実装ですね。

    walt.id

    こちらは初出かもしれませんが、JFFのPlugfestなどにも出ていたものです。
    その時のデモサイトが残っているのでVC発行を体験できます。

    こちらが期待しているのは
    openid-initiate-issuance://?issuer=https%3A%2F%2Fjff.walt.id%2Fissuer-api%2Fdefault%2Foidc%2F&credential_type=OpenBadgeCredential&pre-authorized_code=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJlN2NlM2M5NS0yMTkwLTQxMGItYmI5MS03MzRkOGY5ZGIzNjIiLCJwcmUtYXV0aG9yaXplZCI6dHJ1ZX0.J7--G169U0x61zOoPSbWUESMDO3_YfBsSvgUiHwT7ZQ&user_pin_required=false
    でした。こちらも同じくdraft 9以前ですね。

    では、Auth0 labとwalt.idは相互運用できるのか

    残念、できませんでした。
    Auth0が提供しているWebウォレットでwalt.idの発行要求を読み取っても反応しませんでしたし、逆も然りでした。



    Auth0が提供しているWebウォレット



    walt.idが提供しているWebウォレット



    マイクロソフトAuthenticator?
    openid-vc://?request_uri=https://verifiedid.did.msidentity.com/v1.0/tenants/2c62f1a6-ff50-4764-96a9-0196ebb1bfff/verifiableCredentials/issuanceRequests/d75e8cb7-e79c-443e-81fd-590536b96b34
    です.......


    早く相互運用性が実現するといいですね。

    Trusted Web推進協議会ユースケース報告会がありました

    $
    0
    0

    こんにちは、富士榮です。

    先週の29日(木)と今週4日(月)の2日間にわたり内閣官房Trusted Web推進協議会のユースケース事業者による最終報告会がありました。

    すでに終了していますが、録画や資料は公開されると思うので見逃した方は是非見てみてください。Verifiable Credentialsを含む検証可能なテクノロジやトラストに係るガバナンスのあり方など実際のユースケースに照らし合わせて、かつ実際のモノを作って実験をしているのでとても参考になります。

    報告会URL

    https://www.toppan.com/ja/joho/social/trusted_web2023_koubo.html#lastreport


    以下、プログラムです(上記ページより)

    プログラム概要

    2月29日(木)
    9:55~10:00開会挨拶事務局
    10:00~11:00報告株式会社電通国際情報サービス(「KYC/KYBに基づいたトラストのある取引」を促進する新しい仕組み)
    11:00~12:00報告Institution for a Global Society株式会社(国際間の教育拡充と労働市場の流動性を高める信頼ネットワーク構築~お金の問題なく学び自らの可能性を広げられる世界へ~)
    12:00~13:00休憩 
    13:00~14:00報告株式会社PitPa(海外人材還流におけるクロスボーダー型個人情報流通システム)
    14:00~15:00報告みずほリサーチ&テクノロジーズ株式会社(ものづくりのサプライチェーンにおける製品含有化学物質情報等の確実な伝達を可能とするChemical Management Platform(CMP))
    15:00~16:00報告SBIホールディングス株式会社(事業所IDとそのデジタル認証基盤)
    16:00~17:00報告Originator Profile 技術研究組合(Trusted Web Advertising System with OP)
    3月4日(月)

    10:00~11:00報告株式会社DataSign(ウォレットによるアイデンティティ管理とオンラインコミュニケーション)
    11:00~12:00報告富士通Japan株式会社(大学技術職員の活躍に向けたスキルの見える化:スキルの質保証と主体的情報開示の試行)
    12:00~13:00休憩 
    13:00~14:00報告シミック株式会社(臨床試験及び医療現場における信頼性及び応用可能性の高い情報流通システム(該当分野:医療・ヘルスケア)
    14:00~15:00報告株式会社ORPHE(下肢運動器疾患患者と医師、研究者間の信用できる歩行データ認証・流通システム)
    15:00~16:00報告一般社団法人情報サービス産業協会(補助金事業を題材とした法人向け行政手続DX社会基盤化のプレ検討)
    16:00~17:00報告大日本印刷株式会社(共助アプリにおけるプラットフォームを超えたユーザートラストの共有)
    17:00~17:05閉会挨拶事務局



    私はユースケース担当委員もやっていたので、4日(月)の午後に発表のあった、シミックさん、ORPHEさん、情報サービス産業協会さんの3事業者さんのメンタリングを1年かけて担当してきました。

    今回の最終報告会でも簡単にコメントをしたので軽くご紹介しておきます。(詳しくは今後公開される動画をみてください)


    シミック株式会社(臨床試験及び医療現場における信頼性及び応用可能性の高い情報流通システム)

    ヘルスケアのユースケースです。臨床試験に参加する人が身につけているウェアラブルデバイスから上がってくるデータを医療機関および製薬企業へ同意を持って共有していく、という話です。さらにその際にデータが途中で改竄されていないことを検証可能にする、そしてデータ連携先となる医療機関や製薬企業の正当性についても検証可能にしていくということを目指しています。FitbitなどのウェラブルデバイスにKeyChainのコアを組み込んでデータへの署名をしていくという仕組みで実装しています。

    私がコメントしたのはこんなところです。

    • PHRの観点では同意管理が重要な中、従来は個別でなんとなくな管理DBを作ってきたことを考えるとユニバーサルな仕組みとして応用可能性があり非常に大きな一歩となり得ると思う
    • 今後スケールしていくためには、以下の3点が大切である
      • より多くのウェアラブルデバイスベンダの巻き込み
      • より多くの医療機関、製薬企業の巻き込み
      • 個人の巻き込み
    • デバイスベンダを巻き込むにはインセンティブ設計とオープンネスが必要なので、治験に利用できるという認定などの制度設計との平仄合わせが必要になるのと、KeyChain以外の実装でも互換性を持ちつつ実装できる方法の検討が必要になりそうである
    • 個人の巻き込みの観点ではCGMのようにデバイスの普及とセルフメディケーションと医療費控除への繋げていくなどの仕組みも必要になりそうである

    あまり当日は時間がなかったので技術面ではツッコミませんでしたが、技術標準へのフィードバックもこれらの実験から得られると良いと思います。


    株式会社ORPHE(下肢運動器疾患患者と医師、研究者間の信用できる歩行データ認証・流通システム)

    こちらもヘルスケアのユースケースです。シミックさんのケースとは共通点が多いのでこの2社には協力して実証をすすめていただいていました。こちらは靴にセンサーをつけて歩行情報などをとっていくというシナリオでした。


    同じく、こちらのユースケースへの私のコメントはこんな感じでした。

    • 個人に対するインセンティブ設計が必要
      • ポイ活などとうまく連携して患者向けだけではなく健常者に対しても提供することで予防医療などにも繋げられる可能性があるのではないか
      • 現在の個人へのインセンティブはNFTの付与としているが、同意撤回を行うとポイントの返礼を行うモデルとなっている。これは同意解除にペナルティがある様に感じられる可能性があるので慎重に設計が必要ではないか
    • 医療機関に対するインセンティブ設計
      • 英国と日本の医療制度の比較が紹介されたのですが、英国における利用報酬は当該医療機関に登録された患者の頭数がベースとなる人頭報酬制度、日本の場合は診療行為に対するポイントをベースとして報酬制度となっていることから、人頭報酬となっている方が医師からすると患者が健康であればあるほど登録者数に比べて診療行為の負荷が減らせる=利益効率が良いというインセンティブも作れる可能性があるので、その辺りの制度設計も今後参考にできると良い
    • UXに関して
      • これはこのユースケースに限った話ではないのですが、Walletを使うモデルだとどうしても事業者のアプリやWebサービスとWalletのインタラクションが発生、どうして別の2つのモノを合わせて使わないといけないのか?を個人が受け入れられないケースがあると思います
      • まさにLaws of IdentityのJustifiable Partyって話だと思いますが、ユーザから見て本当に必要なのかが明確にわからない登場人物がインタラクションの中に入ってきてしまうのでUI/UXの面でうまく説明もしくはシームレスな遷移など工夫が必要だと思います

    一般社団法人情報サービス産業協会(補助金事業を題材とした法人向け行政手続DX社会基盤化のプレ検討)

    こちらは行政サービス(G2B)のシナリオですね。法人が行政手続き(補助金申請など)を行う際に必要となる法人確認情報(実在性確認+業務実態に関する情報)、その中でも特に業務実態に関する情報(いわゆるKYB情報)を民間の事業者の発行するエビデンスを集めてくることで信頼性を上げていきましょう、というシナリオでした。

    こちらも私のコメントはこんな感じでした。
    • コミュニティについて
      • 事業スキームとしてコミュニティ形成が大切かつこのモデルになるとG2B文脈においても金融機関や携帯キャリアなどのKYC/KYB提供事業者をコミュニティの一員として迎え入れる必要が出てきます
      • 一方で金融機関や携帯キャリアなどからするとなぜこのコミュニティに参加しなければならないのか?儲かるのか?が関心事となるはずなので、彼らにとってのビジネスの可能性をどうやって示せるのか?は重要なポイントになるはずです
      • そのためにもまずは行政サービスがファーストペンギンになって、その後でこのスキームは民間サービスでも利活用できるんだ、ということを広げていくムーブメントが必要になってくるんだと思います
    • Walletについて
      • どうしてもWalletというと個人のスマホに入ったアプリケーションを想起させてしまうので、法人Walletは別の言い方を含めて考えた方がよさそうです
      • 個人の場合は発行と提示を切り離すことによるプライバシーインパクトの低減などWalletを使うベネフィットは語りやすいのですが、法人の場合は単にポータルとAPIでいいんじゃない?という意見も出てくると思います


    他にも多くのユースケース実証が行われましたので先日発行されたホワイトペーパー3.0と合わせてみてみてください。今後Verifiable Credentialsを使うことを検討されている方々にとっては必須の情報ばかりだと思います。

    mDL(モバイル運転免許証)の実装もそろそろ

    $
    0
    0
    こんにちは、富士榮です。

    Verifiable Credentialsをやっているとクレデンシャルフォーマットをどうするの?という議論によく出くわします。SD-JWT VC、W3C VC、AnonCred、ISO mdocなどなど。。

    昨年のEICのパネルより


    この図にある通り、OpenID for Verifiable Credentials関連スペックは、さまざまなクレデンシャルフォーマットに対応していて(というかフォーマットアグノスティックな設計になっていて)、ISO mdoc(ISO 18013-5)にも対応しているわけです。

    と言いつつ、ISOのドキュメントが有償ということもありVCに比べるとちょっと手が出しにくいのも事実です。(私は買っちゃいましたが)

    とはいえ、カリフォルニア州で実際にmDLとして使われていたり、EUや日本でも実装が進んでいたりするわけなのでちょっと勉強しておきたいところです。

    ということで実装をしてみたい人たちにお役立ちな情報は少しだけ。

    Oktaが提供しているAuth0-labです。

    そして、もちろんAuthleteの川崎さんの実装と解説は必見です。


    なお、CBORをオンラインで手軽にデコードできるツールもありますので必要に応じてこちらも使っていきましょう。


    わたしも徐々に実装を試してみようと思います。


    MOSIPもVerifiable Credentials関連モジュールを組み込んでいるみたいです

    $
    0
    0

    こんにちは、富士榮です。

    昨日、某ニュースを見ていたらMOSIPの解説記事が目につきました。

    そういえばざっくりしか知らないなぁ、と思ったので読んでいたのですが、どうやら最近InjiというVerifiable Credentials関連のモジュールの組み込みをしているんですね。

    記事

    MOSIP, the Unneglectable Force in the Global South

    https://medium.com/@identitywoman-in-business/mosip-the-unneglectable-force-in-the-global-south-a7866535b46e


    MOSIPのアーキテクチャ図(記事より)

    記事の中ではこう記載されています。

    MOSIP has recently added a Verifiable Credentials module Inji, which supports the issuance of Verifiable Credentials, a digital wallet tool for verification, and is looking to offer tools and services for trust and governance. It is still unclear how this module interacts with the MOSIP architecture. But we look forward to learning more about it at MOSIP CONNECT.

    で、Injiです。

    https://docs.mosip.io/inji


    Key componentsとしてこれらが紹介されていますが、まだWalletしかリリースされていないようです。

    Inji Mobile Wallet: A secure, trustworthy, dependable, and decentralized mobile Verifiable Credentials wallet. It allows users to download, manage, share, and verify verifiable credentials. 

    Inji Web: An easy-to-use web portal that makes credentials accessible to everyone. It enables users to download, print, store, and share verifiable credentials physically. [Available starting March 2024 release]

    Inji Certify (issuance): A platform to issue credentials of any type in multiple formats. It allows issuers to create, sign, issue, bind, and store/hold verifiable credentials. [Available starting March 2024 release]

    Inji Verify: Tools and utilities for consuming and verifying credentials. [Available starting March 2024 release]

    Inji Infra: Tools and utilities for revocation, ledger, status, resolution, and federation of verifiable credentials. [Future Wishlist]

    Inji Govern: Frameworks to define policies, schemas, assurance, and parties in the context of verifiable credentials. [Future Wishlist]


    現状、使うには登録フォームから申し込む必要があるようです。

    アフリカや東南アジアの国々などインド発でOSSということもありMOSIPに注目しているところも多そうなので、Walletを含め普及が一気に進むとしてらグローバルサウスから、なのかもしれませんね。

     

     



    統合認証シンポジウム(佐賀)に参加しています

    $
    0
    0
    こんにちは、富士榮です。

    毎年3月に佐賀大学で開催されている統合認証シンポジウムに参加するために4〜5年ぶり?に佐賀大学に来ています。大学や研究機関でID基盤の企画や運用をしている方々がたくさん参加される歴史あるシンポジウムです。
    佐賀大学ホームページより

    IAL2/AAL2のロードマップを作ろう:学認のサポート:佐藤先生(東京大学・学認)

    大学や研究機関におけるID保証の必要性の話です。
    文科省としてもオープンアクセスを推進しているのが大きな理由ですね。
    オープンアクセスとは・・

    このような状況への対処とインターネットの普及を受けて学術情報をインターネットから無料で入手でき、誰でも制約なくアクセスできるようにするというオープンアクセスの発想が1990年代に生まれた 


    組織が研究者のアイデンティティを保証した上で、研究者がそれらのアイデンティティを使って研究活動を行う、というのが基本的な考え方です。すでにNIIではGRDM、Jairo Cloudという基盤を運用していて、各機関のIdPを使ってログインして利用するのが基本的な使い方です。

    この枠組みがいわゆる「学認」、学術認証フェデレーションなわけですが、まだ全大学が参加しているわけではない、という課題があります。
    これはオンプレミスでShibboleth IdPを建てて運用していく、というのは負荷も高いのでMSやGoogleのアカウント管理(要するにGoogle WorkspaceやMicrosoft 365ですね)や、IDaaSサービスを使っていく必要があるので、学認としてもサポートしていこうとしている、ということです。

    その一つの取り組みとして、ここ3年ほど「次世代学認」という旗印のもの、質の高いIdPの運用を可能にするにはどうするのがいいのかを模索してきたわけです。その取り組みに加えて新たなミッションとしてより多くの大学がサービスを享受するにはどうすればいいのか?を考え始めており、そのために学認の求めるIAL/AALを定義してIDaaSやIdPの構築をする際のガイドラインとして提供しよう、という話になっている、ということですね。(こちらの作業部会には私も参加しておりましてサポートさせていただいております)

    この辺りをNIST SP800-63をベースに設計をして行っているのはデジタル庁がやっていることと似ていますね。
    こちらの会議にも私は参加していまして、先日の会議の議事録が最近公開されていますのでご参考までに。

    本気でこれを推進していこうとするとなかなか難しい話も多く、ポリシー策定等の文書を作り、リスク評価、実現可能性の評価、予算・人員の確保、構築、としっかりと計画を立てて進めていかないといけないですね。
    現在、そのために「中規模実験」として意見交換〜文書化を進めています。来年度はシステムに関する技術的なところ(プロトコルやIdPの構成など)も進めていく予定なので参加機関募集!というアナウンスもありました。

    他にもAALにも触れられています。Google AuthenticatorやMicrosoft Authenticatorやパスキー(Face IDやWindows Helloなど)などの新しい認証器がたくさん出てきていますが、しっかりリスク評価をした上で認証器レジストへ登録して公開する、という動きもあります。FIDO Metadataの学認版って感じですね。


    学認対応IdPホスティングサービス実証実験とそこから得られた課題と対応:清水先生(NII)

    学認参加機関を増やしていかないと先のオープンアクセス・オープンサイエンスが実現しないわけなのですが、そのためには各大学や機関がIdPを構築する必要があるわけです。このあたりはそれなりにハードルも高いので、学認対応IdPホスティングサービスをNIIが中心に提供していくことを検討している、という話です。
    本格提供に先んじて2023年3月〜実証実験を行い、参加機関と協力して課題のあり出しなどを進めてきたそうです。

    加えて自組織に所属していない学認未参加機関に所属している研究者と共同でSPを利用する際の扱いをどうするか?についても大きなテーマでNIIが提供している認証プロキシ(Orthros)を利用することも検討されてます。このあたりは実証実験から出てきた課題ですね。


    京都大学におけるOrthrosの活用に向けて:中村先生(京都大学)

    京都大学で進めている研究DXの取り組みの推進においては「サービス主導型選択的多要素認証システム」がテーマになっているということです。
    すでに教員・学生には多要素認証システムを導入しているということですが、学外研究者に関するID保証強度をどのように高めていくか?というのが次の取り組みとなっているわけですね。これはこれまでのセッションでも出てきたオープンアクセスの話題そのものっていうことです。しかし外部ユーザとして名誉教授も入ってくるんですね・・・大学のID種別多すぎです。

    ここで登場してくるのがOrthrosってことです。
    外部の機関の提供するサービスを使ってIALやAALを補強していくためのHubのような役割となるシステム(認証プロキシ)として利用するイメージです。

    これは重要な示唆ですが、大学におけるID管理がますます重要になってきている、ということが挙げられています。やはり研究データは非常に重要なもので国家レベルの機密情報に当たるものもあるわけなので、研究者の本人確認〜ID保証(IAL/AAL)が非常に重要になってきているということです。

    この辺りを学内認証基盤と学外の利用者を対象としたOrthrosをうまく活用して安全な世界を作っていけると良いですね。

    公開鍵暗号方式に基づく認証機能の分離:大神さん(LINEヤフー)

    パスワードレスの話です。先日発表されていたPKaaSの話ですね。
    参考)PKaaSデモ

    まずはパスキーの説明です。

    次にLINEヤフーさんのパスワードレス認証の取り組みについて紹介がありました。SMS認証も合わせると2017年からパスワードレス認証の仕組みを提供しているので、かなり早いうちから対応を進めていました。さすがです。

    すごい数のユーザがすでにFIDO認証を、そしてパスワードレス認証をしているんですね。

    一方でパスワードレス認証の課題にも触れられています。
    • IdPがFIDOに関する機能を実装すること
    • IdPを運用する上で必要なこと
    が結構あるので、この辺りを共通化してコンポーネント・サービスとして提供しよう、というのがPKaaSってことですね。要するに機関のIdPはID管理に注力して認証に関する情報管理(特にFIDOだと公開鍵の管理などが該当)はクラウド(PKaaS)に任せるのはどうだろうか?という提案です。

    実装方式は2つあるそうです。リダイレクトするかバックエンドでAPIを呼び出す方法です。

    リダイレクトの場合のoriginはPKaaSになるんでしょうか。そうなるtお大学IdP側のフィッシング対策にはならなさそうですので、どちらの方式で実装するかは考えたほうがよさそうですねぇ。

    そういえば東大とヤフーさん共同でTrusted Webの実証をしていましたね。


    ハイブリッドクラウド環境における認証基盤とクライアント端末の運用:石丸さん(名古屋工業大学)


    NPS経由でAzure MFAを使っているんですね。Radiusを使う場合は確かにこういう構成になります。
    そういえば昔AD FSとOpenAMの連携をやったなぁ、、という記憶が蘇ってきました。

    しかし、この辺りはあるある過ぎて・・・私は過去に3日間同期完了まで待っていたことがあります。。。


    検証可能な資格情報によるデジタル学生証・職員証の検討:伊東先生(九州大学)

    ジェイズコミュニケーションズさんとの共同プロジェクトなんですね。

    JWSの話かと思ったらVCの話でした。

    どんな機能をデジタル学生証に載せるか、は結構考え所ですね。個人的な意見としては色々な機能を搭載していけばいくほど標準スキーマから離れていく気がするので難しいところだと思っています。

    管理方針についても話がありました。大学で発行・失効などを集中管理するということでしたので、VCである必要性はどこまであるのかな?というのはちょっとした疑問でした。
    VCサンプルというかJWTも見せていただけました。。。。

    発行・提示のプロトコルは独自っぽいですね。
    検証時にもIssuerに問い合わせに行くようです。

    ユースケースはまだ想像がついていないと言うことでしたが、最後にデジタル名刺なんじゃないかな?とういこともおっしゃっていました。同意です。

    質疑応答でも出てきましたが、学生証のユースケースで難しいのは試験のときに持ち込めない、という点なんじゃないでしょうか。


    Shibboleth IdPにおけるFIDO2認証対応 事例報告:大谷先生(佐賀大学)

    ワンタイムパスワードをメインで使ってこられていたということです。

    Shibboleth IdPをFIDO2対応させました、とうことです。
    ベースはNIIが公開しているFIDO2プラグインを使ったそうです。
    当時はShibboleth公式版が出ていなかったからですね。
    ちょうど最近オフィシャルからもアルファ版が出ていますので、今後はこちらも検討されていくのかな?と思います。ただShibboleth v5以降でしか使えないみたいなのでほとんどの大学では厳しそうです。

    まだ管理型機能などはないと言うことで実環境で使うにはまだまだ手を入れないといけなさそうですね。
    いずれにしても大学がリテラシーもバラバラな人たちがたくさん集まる場所でもあるのでパスキーをうまく使えるようになると良いと思います。

    こんなところです。
    来年も参加できるといいなぁ、と思いました。

    OpenID Foundationの提供するテストスイートの開発者(Javaプログラマ)の募集が出ています

    $
    0
    0
    こんにちは、富士榮です。

    OpenID Foundationは同団体が開発している各種仕様やプロファイルに関する認定プログラムを提供しています。

    みなさんが開発しているOpenID Providerなどがこのプログラムに認定されると上記のページに掲載され、安全に使えるソリューションであることが認められた形になります。
    最近ではOpenID Connectのコア仕様だけではなく、FAPIやOpenID for Verifiable Presentationに関するテストも開発されています。

    今回は認定プログラムに適合することを確認するためのテストスイート自体の開発をするためのJavaプログラマを募集している、という話です。



    我こそは!という方は応募してみてはいかがでしょうか?
    プロトコルやプロファイルにとっても詳しくなれると思います。

    EUのDigital Identity Walletのリファレンス実装が公開されています

    $
    0
    0

    こんにちは、富士榮です。

    各国でデジタル・アイデンティティ・ウォレット(DIW)の検討や実装が進んでいますが、先行して検討が進んでいるEUの実装やアーキテクチャ・リファレンス・フレームワーク(ARF)を参考にすることが多いと思います。

    ARFはこちら

    The European Digital Identity Wallet Architecture and Reference Framework

    https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework


    今回はドキュメントではなく、Digital Identity Wallet並びに関連するモジュールがgithubで公開されている、という話です。ビルドすればWalletが作れるのでみなさんも試してみると面白いと思います。

    こんな感じで動くようです。

    レポジトリより

    こちらで公開されています。

    https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md

    公開されているのは、以下のモジュール群です。

    • Wallet Core(Android) and Wallet Kit(iOS) Coordinator Libraries
      • Wallet Core(Android)
      • Wallet Kit(iOS)
    • Proximity Sharing iOS Libraries
      • mDoc Security(iOS)
      • mDoc Data Transfer(iOS)
      • mDoc Data Model(iOS)
    • Proximity Sharing Android Libraries
      • mDoc Data Transfer(Android)
    • Remote Presentation iOS Libraries
      • Presentation Exchange(iOS)
      • SIOPv2 and OpenID4VP protocols(iOS)
      • SD-JWT(iOS)
    • Remote Presentation Android Libraries
      • Presentation Exchange(Android)
      • SIOPv2 and OpenID4VP protocols(Android)
      • SD-JWT(Android)
    • Issuing iOS Libraries
      • OpenId4VCI(iOS)
    • Issuing Android Libraries
      • OpenId4VCI(Android)
    • Wallet Data Storage and Cryptographic Management iOS Libraries
      • mDoc Document Storage (iOS)
    • Wallet Data Storage and Cryptographic Management Android Libraries
      • mDoc Document Storage (Android)
    • Wallet UI App and demo App for Android and iOS
      • UI / Demo App (Android)
      • UI / Demo App (iOS)
    • Verifier Apps and Services
      • Web Verifier
      • Restful API (web-services)
    • Issuing Apps and Services
      • OpenId4VCI issuer (Python)
      • OpenId4VCI issuer (Kotlin)

    結構膨大ですね。

    日本でもDataSignさんが進めているOWND ProjectなどオープンソースでWalletなどの実装を公開する動きが出てきていますし、開発者のみなさんには良いことだと思います。

    OWND Project

    https://github.com/OWND-Project


    自己主権型アイデンティティは本当か?情報銀行からの学びはあるのか?

    $
    0
    0
    こんにちは、富士榮です。

    ちょっと前に情報銀行の認定事業の最後の一つだったDataSignさんのPaspitがサービス停止をしたことで通常認定がゼロになった、というニュースが界隈で出ていました。
    DataSignさんのニュースリリース

    情報銀行「paspit」サービス終了のお知らせ 

    https://datasign.jp/blog/paspit-announce/ 

    結果、IT連盟の通常認定がゼロになっています。

    https://tpdms.jp/certified/


    ちなみにP認定はまだありますが、そもそもP認定は「「情報銀行」サービス開始に先立って立案した計画、運営・実行体制が認定基準に適合しているサービスであることを認定するものです。サービス開始後において運営・実行、改善を図り、『通常認定』の取得が条件となります(P認定の更新は不可)。」という定義なのでサービスが開始されていない(もしくはサービスを開始する前の検討段階)のものなので、実質サービスとして提供されているものではありません。なので本当にゼロ件です。

    この分野はそれほど詳しいわけではありませんが、そもそもの情報銀行の意義は利用者が自分の情報を適切に扱ってくれるサービスに適切に渡すために情報銀行サービス事業者に情報を信託することで安心してサービスを利用できるようにしましょう、という取り組みだったはずです。つまり、前提として情報銀行サービスが情報を提供する先の審査を行い、適切に情報を扱うことが確認できている場合に情報を提供することでリテラシーのあまり高くない利用者を保護しましょう、という話です。これは正に信託銀行が利用者の代わりに株式や資産の運用を行うことで利用者個人が過剰に責任を負うことなく安全に資産運用ができるようにしましょう、という話と同様のもので、その意味で情報(信託)銀行だったわけです。
    しかしながら、実態として情報銀行においては、この信託銀行や銀行の本来の価値である利用者に変わって比較的安全に運用を行いましょう、という部分が私たちの頭から抜け落ちていたように感じます。結果、単に個人情報をサービス事業者に預けると利子(ポイントなどのリワード)がつく、雑に言うと「個人情報を売っている」感覚に近くなっていき敬遠されていく、というサイクルだったのかな?と思ったりしています。

    ちなみにこの話は本日のコラムのテーマでもある「自己主権」についても隣接する話題だと思っています。今日はそんな話です。

    自己主権とユーザの責任

    これまでも自己主権型IDの責任モデルについてあちこちでお話してきました。
    (2019年ごろによく使っていたスライド)


    また、主権?という話についても正直疑問に思っている、という話も何度もしてきました。
    (昨年のOpenID TechNight、分散型ID勉強会の資料より)


    この辺りを踏まえて少し自己主権型アイデンティティについて考えてみましょう。
    簡単にまとめると、自己主権アイデンティティのモデルにはユーザの責任が重くなりすぎると言う点で以下の通り課題があると思っています。
    • 自己主権の一番の難しさは結果的にユーザに責任を押し付けることになること
    • つまり、ユーザは誰に情報を提示して良いのかを自身の責任で判断しないといけない
    従来のID連携のモデルでは多くの場合RPとIdPの間で事前の信頼関係構築が前提となっていました。具体的にはIdPとRPはトラストフレームワークなどで表現されるID連携のために必要なルール(例えばRPは受け取ったID情報を適切に扱うこと、など)に基づき事前に合意している前提がありました。
    そのため、IdPにアカウントを登録するユーザはIdPが連携できるRPをある程度審査していることを含めある程度納得した上でRPを使っているという建て付けになっている(利用規約とかポリシーに記載されている)わけです。

    ただし、あくまでIdPがある程度担保してくれるためにはユーザが使うRPの情報などをIdPが知ることができてしまう、という点においてプライバシーリスクが指摘され、Walletを使うことでIssuer/Verifierの間にWalletが入り、ユーザ自身の意思を反映した形でID情報のやり取りが行われる=自己主権でありプライバシー上の問題がなくなる、という話になってきたわけです。

    ところが、このことによりIssuerは、Verifierを事前に審査することができなくなるわけで、Verifierが適切なのかどうかを判断できず、あくまでユーザが自身の責任でVerifierに情報を提供しなければならない、ということになってきてしまいました。

    果たしてユーザは責任をとれるのか

    「自己責任」の一言で済ませられるのであればそれで議論は終了なわけですが、人類はそれほど賢いわけではありません。いつまで経っても秘密鍵やパスワードの管理を人類はできるようになっていないわけで、VCがWalletに入っていても正しく管理できるようになるとは思えません。
    暗号資産についても結局は事業者に管理を委託しちゃってますよね。本来はあれもBitcoinのアドレスを自分で管理することもできるはずですが、結局はカストディアンに頼るのが自然な状態になっているわけです。

    と言うことでどんな対応ができるのか考えてみる

    結局はWalletをIssuerが管理化に置き、VCを提示できるVerifierを制限する、などが必要になるのかもしれません。しかしIssuerが管理をするモデルになると、従来のID連携モデルでIdPが利用者が使っているRPを知れてしまう、という問題の解決にならず、Walletモデルの意味がなくなってしまいます。
    となると、もう選択肢になり得るのはWalletプロバイダが提示できるVerifierを制限するという形が良いのかも知れないな、と最近は思っています。
    もちろん、Verifier毎に専用Walletを使う、などの対応をしないと今度はWalletプロバイダがユーザが使っているVerifierを知れてしまうという問題が出てくる可能性もあるのですが、このモデルだと結局自己責任モデルにしかなりませんし、Verifier毎にWalletが大量にインストールされているスマホを持ちたいとは思いません。(それこそカスタムURLスキーム問題で技術的にもややこしいことになりますし)

    結局はユーザが安心してVerifierにID情報を提示することができる状態を作る必要があるわけなので、ユーザが誰かを信頼して委託する(つまり信託する)必要があるわけです。Walletプロバイダのモデルだと、ユーザは従来のID連携モデルでIdPを信頼したのと同様にWalletプロバイダを信頼することになります。
    こうなると、Walletプロバイダに情報が集約することは諦めるしかないわけなのですが、
    • ID連携に比較してIdPへのCall home問題はなくなるのでIdPの可用性を含む全集中度合いは下げられる(別の切り口だが)
    • Walletプロバイダが本当に認定済みVerifierに対してVCを提示したかどうかはわからないようにWalletを作ることはできるはず
    ということは考えられるわけで、ID連携のモデルとの差別化はできそうです。

    これを実現するためには、Walletプロバイダが審査済みのVerifierのみにVCを提示可能にするなどの機能を実装し、VC提示の際に許可・不許可のリストをローカルで参照する仕組みになっていればWalletプロバイダは審査済みのVerifierのうち、実際にユーザがどこに対してVC提示を行ったかは検知できないようにはできるのではないかと思います。(本当にそんな実装になっているかどうかは信頼するしかないとは思いますが)

    このことで、
    • ID連携におけるIdP万能という状態からは少し前進できている気はする
    • 多分、次のVC関連のビジネスはWalletプロバイダが本当の意味での情報銀行(提示先の審査による安心の提供)としての機能を提供することなのかも知れない(どこまで利用者からお金を取れるかは未知数だけど)
    と思えます。
    この辺は引き続き皆さんと意見公開をしつつモデルを考えていけるといいですね。

    パスキーの実験に使ったコードをgithubにあげました

    $
    0
    0

    こんにちは、富士榮です。

    そういえばパスキーの実験をしていた頃のコードを公開するのを忘れていた気がするので公開しておこうと思います。

    これまでのパスとでやったことはこちらです。


    あくまで実験的に実装した内容ですので参考までに、です。

    そろそろ忙しくなってきたのでOpenID Providerのログインにパスキーを組み込むのは少し先になりそうです。。。

    OpenID Foundatioon Hybrid Workshop@Googleオフィス(マウンテンビュー)

    $
    0
    0
    こんにちは、富士榮です。

    次回のIIW(Internet Identity Workshop)の前日(4月15日)に開催されるOpenID Foundation Hybrid Workshopのレジストレーションが始まっているので忘れずに登録しましょう。(2月後半にレジストサイトがオープンしたので速攻申し込みました)

    先日日本でもOpenID Summitの前日に開催されたワークショップですね。
    その時の様子はこちらです。

    今回はマウンテンビューにあるGoogleのオフィスで開催されます。

    こちらは2022年の4月に同じくIIWの前にOIDF WorkshopがGoogleで開催された際の写真です。このチャリ欲しいなぁ。。と思った記憶があります。

    今回は私も現地参加の予定なので様子をリポートしたいと思います。


    OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が開始されています

    $
    0
    0

    こんにちは、富士榮です。

    先日ポストした、OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が始まっています。

    Notice of Vote for Proposed Implementer’s Draft of OpenID for Verifiable Credential Issuance

    https://openid.net/notice-of-vote-for-proposed-implementers-draft-of-openid-for-verifiable-credential-issuance/


    個人でもOpenID Foundationのメンバになれますので(50ドルかかりますが)、ぜひ登録して投票してください。


    SIDI Hubの2024の戦略が発表されました

    $
    0
    0

    こんにちは、富士榮です。

    先日のOpenID Summit Tokyoやその前日に開催されたOpenID Foundation Hybrid WorkshopでOIDF Executive DirectoryのGail Hodgesのキーノートで触れられたSIDI Hub(Sustainable & Interoperable Digital Identity Hub)の今後のプランと今年のアクションアイテムが公開され、2024/3/31までフィードバックを募集しています。


    SIDI HubのWebページのトップからダウンロードできるようになっています。


    ちょっと中身をみていきましょう。

    SIDI Hubが解決を目指す課題とは?


    SIDI Hubの名前の通り、デジタルアイデンティティって全然相互運用できないよね、ということを最大の課題として設定しています。

    以下、Deeplでの機械翻訳です。

    人と企業は国境を越える。将来、人々は、通貨交換を期待するのと同様に、国境を越えて日常生活でデジタル・ アイデンティティを使用したいと思うようになるだろう。残念ながら、多くの問題が国境を越えた相互運用性の障害となっている:

    • 数十のデジタル・アイデンティティ・エコシステムがその管轄区域内でサイロ化されている。
    • OECD のデジタル ID 勧告には、国境を越えた利用を可能にすることが盛り込まれているが、 38 カ国の加盟国がどのように実現できるかについての技術的または政策的なロードマップはない。
    • どの国、地域、標準化団体、非営利団体、民間団体、多国間に も国境を越えた相互運用性を実現する権限がない。
    • 単一の標準が「すべてを支配」する可能性は低いため、技術スタック間のデジタル ID 相互運用性は技術的には可能であるが、達成および維持は非常に困難である。 
    • 悪質な行為者が脆弱なインフラ(AIディープフェイク、サイバー犯罪、COVID-19)を利用するため、不作為による機会費用が発生し、人々やビジネスは高いレベルの摩擦に直面する。
    • ポリシーを解釈し、製品や実装で簡単に実施する仕組みがなければ、ビジネス・コンプライアンス・コストは増大し続ける。
    • デジタル・アイデンティティが果たすであろう重大な役割を理解している人は、アイデンティティ・コミュニティ以外にはほとんどいないため、明確で透明性の高いコミュニケーションが重要である(誤った情報を避けることも同様)。

    ということでSIDI Hubの目的は?

    クロスボーダーで使えるデジタルアイデンティティを実現するために必要なものを定義しましょう、ということです。

    なぜSIDI Hubがこんなことをやるの?


    なぜなら、SIDI Hubは、

    (1) デジタル ID インフラ、標準、および政策に責任を持つ (2) SIDI ハブに価値を見出す、グローバルなエコシステム全体 からの利害関係者のコミュニティ 

    ワークストリームおよびワークショップにおける SIDI ハブの参加者は、共有されたロードマップ、 解決すべきギャップ、および改善策を含む、国境を越えた相互運用性の「良い姿」を具体 化するのに役立つ。

    我々は、この課題に対する共通のコミットメント、国内主権と国内法および国際法の尊重、参加組織の活動の尊重、そして共通の文化(コンセンサス、包括的、透明性、健全な議論など)を持っている。 

    SIDIの協力は、組織がその使命に照らしてインパクトをもたらすための「泳ぐ車線」を明確にする助けにもなる。

    であり、逆にいうと、
    法人
    統治機関 
    標準化団体
    オープンソースコードプロバイダ
    市民権団体
    NGO 
    多国間組織
    コンサルティング団体
    ベンダー

    ではなく、 

    SIDI Hubは、政府やその他のエコシステム参加者が何をしなければならないかを指示することはできません。
    ということです。

    他国間連携をする際のアプローチは非常に難しいですね。どうしても政治色や経済安全保障などの視点が入ってきてしまうので、国際標準化機関でやってしまうと国力が小さい国々の意見などが反映されにくくなったりする、というのも背景なのかもしれません。(かといってこのアプローチが成功するとも限りませんが)

    何をして、何をしないのか?

    やること:
    • ギャップ分析
    • SIDI Hunの目的に向かって推進するための活動
      • チャンピオンユースケースの選定
      • 標準化団体へのアプローチ
        • 各団体が策定している標準への働きかけ
      • デプロイメント
        • オープンな相互運用性試験の実施の働きかけ
        • 条件を満たすオープンソースにフォーカスを当てる
      • ポリシー
        • トラストフレームワーク間のマッピングを行う
      • オペレーション
        • 会合の開催
        • フィードバックの反映
        • 他の動きとの整合性をとる

    やらないこと:

    • 以下のような口出しはしない、ということです
      • 政府に対してどのような法律を策定しなければならないか
      • 非営利団体がどのような決定を下さなければならないか
      • 標準化団体がどのように仕様を変更しなければならないか

    誰が参加するの?

    色々な方達が関わっていますね。
    • 国連やワールドバンクのような多国間組織
    • EUや個々の国々の政府機関
    • 非営利団体
    • 標準化団体
    • 学術機関
    そしてそれを下支えするための企業や市民団体、メディア、エキスパートたちももちろん参加者となります。
    実際昨年の11月にパリで開催されたイベントにはOpenID Foundationはもちろん、日本政府からも参加しています。他にもおなじみの団体がありますね。

    結局何をやるの?

    先に触れたパリの会合の参加者からSIDI Hubを実現するためには何をすべきなのか?を募ったところ、以下に集約されたとのこと。

    • チャンピオンユースケースを定義する
    • デジタルアイデンティティの最低限の要求事項をまとめる
    • トラストフレームワークのマッピングを行う
    • 成功の指標を定義する
    • SIDIのガバナンスを定義する
    どれも重要ですね。
    想像するに、例えばトラストフレームワークのマッピングができると、日本における犯罪収益移転防止法の元で運営されている事業者で本人確認されたデジタルアイデンティティは国外でも確認済みとして通用するかどうか?という視点は非常に大事だと思います。逆にここでちゃんとマッピングをしておかないと他国において日本の本人確認は役に立たない、といった事態になってしまうのかもしれません。

    ということで、先ほど触れた様々な参加組織から上記のトピックスに対応するためのワーキンググループを組成しましょう、という提案がなされています。


    みたような人たちがCo-Chairとして手を挙げています。


    今後どのような活動をするの?

    各個別の活動は置いておいて、全体としてのロードマップが示されています。

    一番大きいのは次のリオデジャネイロでのG20に向けたインプットをどう作っていくか、というところでしょうね。


    色々とイベントの企画も進みつつあります。
    Q4(10月)には東京かシンガポールでもイベントの開催が計画されています。
    楽しみですね!


    こういう国際連携モノは時間もかかるしコンセンサスを取ることも難しいと思います。さらにいうと最終的に各国が社会実装するかどうかが肝になると思いますが、そのあたりはSIDI Hubでは口出しをしない体裁になっているあたりも不安要素ではあります。
    とはいえ、ちゃんと解かないといけない課題ではあるので日本からもこのような取り組みにちゃんと向き合うようにできると良いのではないでしょうか?


    Identiverse 2024のアジェンダが公開されています

    $
    0
    0
    こんにちは、富士榮です。

    先日はEIC(European Identity & Cloud Conference)のアジェンダが発表された件を書きましたが、今回はEICの前の週にラスベガスで開催されるIdentiverseの件です。
    今回は2週連続でイベントなのでラスベガス経由のベルリンの長丁場になりそうです。(そういえば前回のIdentiverseでMicrosoftのAnkur Patelが今で言うEntra Verified IDの発表をしたんだったなぁ、、と遠い目。セッションの後で彼を捕まえてPreviewプログラムに参加させてもらったところからVC人生?が始まっている気がします)

    まずはIdentiverseとは?からです。
    こちらのポストでも書きましたが、世界四大アイデンティティイベント(4は適当)の一つで、もともとPing IdentityのAndreが始めた旧Cloud Identity Summitと言われていたカンファレンスですね。ラスベガス開催になってからは参加できていませんでしたが、今年は参加しようと思います。

    そして、いよいよセッション一覧が公開されました。

    セッション数も多いので、気になったものを。

    Data Sharing Using Verifiable Credentials in the Agricultural Sector

    初日から気になるセッションです。農業とVCをどう繋げたのか是非聴いてみたいセッションですね。

    Global Trends & 2024 Strategy: OpenID Foundation Board Insights

    OIDFのボードの方々による2024年のグローバルトレンドの話です。これは必聴です。


    Enabling a Trusted Ecosystem for the US Pharmacy Supply Chain

    薬局かどうかは置いておいてサプライチェーンにおけるトラストの話題は日本でも大切な話なので、こちらは是非聴いてみたいネタです。


    Untangling the Tangled Web of Digital Identity Online Presentation

    オンラインでのデジタルIDの提示に関する課題をmDLやVC、Walletなどを中心に議論するパネルです。標準化の中心人物が集まって議論するのを生で見ることができるのもこのようなグローバルイベントの醍醐味です。


    Digital Identity, the G20, and the SIDI Hub Survey

    ちょっとチョイスするセッションのGail率が高い気がしてきましたが、SIDI Hubです。G20に向けて着々と進んでいますね。



    Lessons Learned: Nationwide eID Recovery With Remote Identity Proofing

    ノルウェイのBankIDの方によるeIDのリカバリーをリモートIdentity Proofingでやった事例の話ですね。日本でもマイナンバーカードのスマホ搭載など国民IDのデジタル化が進むとリカバリの問題はついて回るので先行事例を勉強しておくのは大切だと思います。



    Counselors in the Modern Era: Advancing Identity Management

    イアンのセッションなので、無条件で参加です。


    Securing the Foundations of Verifiable Credential Ecosystems

    先日紹介したOID4VCxのFormal Security AnalysisをやっていたDanielのセッションです。今後社会実装をしていく上では必須になると思います。






    その他もたくさん面白そうなセッションがありますが、全体感としてEICに比べてCIAMやパスキーのセッションがバランスよく配置されているな〜という感想です。先端事例も良いですが今目の前にあるビジネスもバランスよく、という感じなんでしょうね。




    Auth0の管理画面へのログインにパスキーを使うと少しハマる件

    $
    0
    0

    こんにちは、富士榮です。

    そういえばAuth0(Okta CIC)の管理画面へのログインにパスキーなどが使えるので使ってみたいと思います。

    ちなみにちょっとだけ癖があります。簡単に書くと、

    • パスキー追加をメニューから実施する場合はplatform認証器は選べない
    • USBキーやOTPなど多要素認証を追加し利用すると「このデバイスでのログインの高速化」を目的としてplatform認証器の登録を促される
    • リカバリはリカバリーコードを利用する
    • どうやらパスキーとしてはUSBなど外部キーを前提に設計されている
    • デバイス登録を目的にplatform認証器登録も使えるが同期される前提はなさそう

    という感じです。最初からplatform認証器が登録できればいいのに。ちょっと実装が古いのかな。


    さて、始める前に基本的な話を。IDaaSを使ってID基盤を構築するときに忘れてはいけないのはIDaaS自体の認証強化とアクセス制限です。

    最低限やっておくべきことは、
    • 管理者アカウントの分離(共有ユーザの排除)
    • 管理権限の適正化
    • 認証強化(多要素認証)
    • ※API実行ユーザも忘れずに!
    くらいでしょうか。
    特にヘルプデスクやオペレータのアカウントも作る必要もあると思うので適切に権限分離は重要だと思います。
    また、日本企業に多いと思いますが、上記に加えてアクセス元の環境の制限(IP制限など)も行いたい、という話も出てくることもあります。(これは働き方改革なのか、ネットワークペリメーター神話がまだまだ生きているだけなのかはケースバイケースです)

    ということでAuth0でも管理画面へのログイン時の認証を強化できますのでやっておきましょう。
    ちなみに、ご存知の通りAuth0の管理画面へログインするためにはローカルログインに加えてLinkedInやMicrosoft Account、Githubアカウント、Googleアカウントが使えます。
    当然、それらのIDシステムもパスキーに対応していたりと認証強化を行うことは可能ですが、今回のテーマはAuth0側でさらに認証強化をする、という話です。

    IdP側の認証強化の結果をこのケースおけるRPとなるAuth0の管理画面はどこまで信じることができるのか?と言う話とUI/UXの関係については別途書こうと思いますが、ざっくり言うと外部IdP(ここで言うとGoogleなど)は認証結果に対する責任は取ってくれない、かつどのような認証手段で認証したのかは教えてくれないので、重要な顧客IDを預かるIDaaSは自前でも多要素認証を実装しておくことが重要です。

    ログインしてプロファイルページを開くと認証手段の追加ができます。
    ちなみに設定が行われいていないテナントでは順次ログイン時に強制的に多要素認証設定を行うように促されるため最近のテナントを持っている方は設定済みかもしれません。

    ということで追加してみます。WebAuthn with FIDO Security Keysをクリックしてみましょう。(なお、ポップアップがブロックされているとエラーになりますので、許可してください)

    登録画面が出てきますね。初めに書いた通りplatform認証器ではなくUSBセキュリティキーが前提となっています。
    登録が終わるとリカバリーコードが発行されるのでコピーしておきます。ちなみにダッシュボードからリカバリーコードは再生成できますので、こちらのスクリーンショットのコードはすでに無効です。

    これで登録が完了しました。

    一旦ログアウトしてログインし直してみます。USBキーが求められます。

    すると、「このデバイスでのログインを高速化」と言われます。

    そしてTouch IDが求められます。

    USBキーとデバイスの両方が登録された状態になります。

    USBキーを使う場面は少なくともSyncされたデバイスでは出番はなさそうです。
    どうもplatform認証器はあくまでデバイス登録を目的としたものとして整理されているようですね。

    しかし、iCloudで同期されているのかと思いつつiPhoneでダッシュボードにログインしてみるとplatform認証器は使えません。
    USBキーが求められるので、仕方なく先ほど登録したUSBキーを使ってログインします。(先ほどYubikey NFCを使ったのでNFCで読み込ませました)

    するときました。先ほどMacで登録したのと同じようにログインの高速化。
    FaceIDを使ってデバイス登録を求められます。

    しかし、すでにデバイス登録をMacでしているのでエラーが出ます。。。


    iCloudで同期されているので登録済みって言われてます。

    やはりパスキーが同期されている想定はなく、あくまでplatform認証器はデバイス登録に特化して利用、あくまで認証は外部キーを使うという整理になっていそうですね。






    外部IdP利用時にRP側"でも"多要素認証を行うべきか

    $
    0
    0
    こんにちは、富士榮です。

    今回は多要素認証の話です。
    ソーシャルIDなどの外部IdPと連携をする際、外部IdP側がパスキーに対応している場合もあり、基本的にRP側はIdPの認証結果を信じて何もしないという文字通り「Relying」な感じで構成されることが多いと思います。

    しかしながら、本当にそれでいいの?とうケースも存在すると思うので、少し深掘りしてみましょう。
    中々難しい話だと思いますが、IdP側(例えばGoogle)で認証を強化するか、RP側(例えばECサイト)で認証を強化するか、もしくは両方か、についてユーザ体験の妥当性を含めて考えていかないといけないところです。
    IdPもRPもそれぞれ責任範囲が異なるので基本的に自分の責任範囲を守る目的で多要素認証を要求していますが、ユーザから見るとなぜ別々に、、という形に見えてしまうことも事実です。

    この問題を根本的なところは先に書いた通り責任範囲の話を理解する必要があるのですが、ツール(技術面)とルール(契約を含め責任論)を合わせてみていかないといけません。この辺りをトラストフレームワークと言われるもので表現をしていくことになります。

    まずは技術的な話

    まずは簡単な話として、技術の話をしていきましょう。(本来はルールの話をした上で技術の話をするのが良いのですが、読者層を考えるとまずは目に見えるところから入るのが良いと思っています)

    本来はIdPがacrやamrで認証手段(例えばパスキーで認証したよ)という情報を渡してあげればRP側はその結果を見て追加でパスキーを要求するべきかどうかの判断をしていくのが良いと思います。ただRPを作ったことがある方はわかると思いますが、
    • IdPによって返すacr/amrが異なる
    • IdPによっては返ってこないこともある
    などの事情があるので、特に複数のIdPとのID連携を行う場合は中々面倒臭いことになります。

    例えば、GoogleのOpenID Connectのサポート状況を見るとドキュメントを見る限りacr/amrに関する記載はありません。


    Entra IDは一応amrの値を返しますが"pwd", "mfa"の2種類しか返せないのでパスキーで認証されても、OTPで認証されても"mfa"になると思います。

    Oktaの例は56さんが試してくれていますがEntraよりは少しマシな程度っぽいですね。

    ということで外部IdPの認証手段までを厳密かつ標準的に取得して利用するのは現時点では結構ハードルが高そうです。
    この辺りは学術認証フェデレーションでは議論が進んでいるのですが、ある程度閉じたコミュニティの中だからできる議論でもあるので、パブリックなIdPだと難しいと思います。


    そもそも論として、なぜ外部IdPと連携するのか?

    また、そもそも論として各IdPをどこまで信じるのか?というか何のために外部IdPを使うのか?というところに遡ってしまいます。
    単に、利便性(プロフィール入力の手間の削減、パスワード登録をさせない)を提供することでドロップ率を下げましょう、という場合もありますし、本気で外部IdPの認証結果に依拠しましょう、という場合もあります。

    登録時にプロフィール入力を自動化してドロップ率を下げましょう、という話だけなら認証まで外部に依存する必要は本来ないと思います。パスワード登録をRP側でさせることでドロップ率が〜〜〜という話であればパスキーを使うなりなんなりしてパスワードに依存しない認証手段を用意すれば良いと思います。
    (認証まで外部IdPに依存することでログインの都度外部IdPにリダイレクトされるとなると外部IdPが落ちていた場合に発生する機会損失などのリスクもありますし)

    認証手段をRPが自前で持つことがリスクという考え方をする方もいるのは事実なので、その場合は外部IdPに頼ってしまうこととのリスクとの天秤で考えるしかないと思います。
    (外部IdP側でアカウント侵害が起きたらどうするの?とか)


    というあたりで外部IdPとの責任問題の話になってきたところで今回は終わりです。
    ある程度答えは見えていると思いますが、次回以降で主要なIdPがどこまで責任を取ってくれるつもりなのか?について少しずつ調べてメモしていこうと思います。

    Entra IDの新しい条件付きアクセスを試す(デバイスコードフロー編)

    $
    0
    0
    こんにちは、富士榮です。

    そういえばEntra IDの条件付きアクセスに新しい条件が追加されましたね。
    今回追加されたのは認証フローという条件で、
    • デバイスコードフロー
    • 認証の転送
    の2つの条件をサポートしています。


    関連するドキュメントはこちらにあります。

    デバイスコードフローはともかく「認証の転送」とは??という疑問はもっともですが、簡単にいうとPCブラウザ等でログインを求められる際にQRコードなどでモバイルデバイスを呼び出してモバイルデバイス側で認証する、という構成を想定した条件です。(Outlookとかであるはず)

    当該する条件に合致するときにブロックしたり多要素認証を要求したりすることができるのがこの条件付きアクセスという機能なので、きっとそのようなシナリオがどこかであったんだと思います。(ちなみにこの機能を使うにはAzure Active Directory Premium P1が必要です)

    ということでポリシーを作ってみます。
    今回はデバイスコードフローをブロックするシナリオで試してみましょう。
    条件としては、
    • 全てのユーザが
    • デバイスコードフロー用のテストアプリにアクセスしようとした場合
    • 認証フローが「デバイスコードフロー」だったら
    • アクセスをブロックする
    というポリシーを作ってみました。
    (上記のスクリーンショットのもの)

    ということでアクセスしてみます。
    デバイスコードフローなので
    https://login.microsoftonline.com/{テナントID}/oauth2/v2.0/devicecode
    に対してclient_idとscopeをx-www-form-urlencodedでPOSTしてあげるだけですね。

    こんな感じでPostmanでリクエストをしてみます。

    あとはレスポンスの中にあるverification_uriにアクセスしてuser_codeを入れてあげれば認証完了です。(通常はこのレスポンスをQRコードにして表示してスマホで読み込んだりさせます)
    今回はそのままverification_uriを開いてみます。

    そしてuser_codeを入れるとログインが求められます。

    今回はデバイスコードフローをブロックするのでポリシーが正常に動いていればアクセスがブロックされます。



    条件付きアクセスは色々と新しい条件がついていてかなりきめ細かいアクセス制御ができるようになってきています。
    アプリケーションの利用シーン(環境など)をベースにいろいろなポリシーを構成してみてください。





    Viewing all 769 articles
    Browse latest View live