[upki-fed:11] Re: Shibboleth IdP への Azure AD proxy 設定（東京大学様の事例を参考に）

[Saito Hironobu <xxxxxx@xxxxxxxxxxxxxxxxxxxx>]

埼玉大学の斎藤です。

中田様、ご教示ありがとうございます。

ブラウザに SAML Tracer を入れましたところ、ブラウザには SAML response 
が期待通りに返っていることはわかりました。
あとは IdP において 下記の NameID の値が $resolutionContext.principal 
に代入されるのが期待されるのですが、そう動作していないという状態です。

ブラウザでキャッチした SAML response だけ、以下に記載しておきます。
--（ここから）--
<samlp:Response ID="_8..5" Version="2.0" 
IssueInstant="2023-06-12T01:31:19.831Z" 
Destination="https://idp.itc.saitama-u.ac.jp/idp/profile/Authn/SAML2/POST/SSO"; 
InResponseTo="_b..1" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://sts.windows.net/0__1/</Issuer>
    <samlp:Status>
        <samlp:StatusCode 
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion ID="_f..0" IssueInstant="2023-06-12T01:31:19.825Z" 
Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://sts.windows.net/0__1/</Issuer>
        ...
        <Subject>
            <NameID 
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">xxxxxx@xxxxxxxxxxxxxxxxxxxx</NameID>
            <SubjectConfirmation 
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="_b..1" 
NotOnOrAfter="2023-06-12T02:31:19.705Z" 
Recipient="https://idp.itc.saitama-u.ac.jp/idp/profile/Authn/SAML2/POST/SSO"/>
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2023-06-12T01:26:19.705Z" 
NotOnOrAfter="2023-06-12T02:31:19.705Z">
            <AudienceRestriction>

<Audience>https://idp.itc.saitama-u.ac.jp/idp/shibboleth</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute 
Name="http://schemas.microsoft.com/identity/claims/tenantid";>
                <AttributeValue>0__1</AttributeValue>
            </Attribute>
            <Attribute 
Name="http://schemas.microsoft.com/identity/claims/objectidentifier";>
                ...
            </Attribute>
            <Attribute 
Name="http://schemas.microsoft.com/identity/claims/identityprovider";>

<AttributeValue>https://sts.windows.net/0__1/</AttributeValue>
            </Attribute>
            <Attribute 
Name="http://schemas.microsoft.com/claims/authnmethodsreferences";>
                ...
            </Attribute>
            <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress";>

<AttributeValue>xxxxxx@xxxxxxxxxxxxxxxxxxxx</AttributeValue>
            </Attribute>
            <Attribute 
Name="http://schemas.microsoft.com/identity/claims/displayname";>
                <AttributeValue>Saito Hironobu</AttributeValue>
            </Attribute>
            <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname";>
                <AttributeValue>Saito Hironobu</AttributeValue>
            </Attribute>
            <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname";>
                <AttributeValue>Saito Hironobu</AttributeValue>
            </Attribute>
            <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"; 
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

<AttributeValue>xxxxxx@xxxxxxxxxxxxxxxxxxxx</AttributeValue>
            </Attribute>
        </AttributeStatement>
        ...
    </Assertion>
</samlp:Response>
--（ここまで）--


Hisaho Nakata wrote on 2023/06/11 13:16:
> Web Browser に SAML Tracer 入れれば、SAML Responce  の内容を確認できます。
>
>
>
>
>
> 日本マイクロソフト株式会社
>
> 中田寿穂
>
>
> ________________________________
> 差出人: Saito Hironobu <xxxxxx@xxxxxxxxxxxxxxxxxxxx>
> 送信日時: 2023年6月9日 17:36
>
>
> 埼玉大学の斎藤と申します。
>
> Shibboleth IdP に多要素認証を導入したく、Azure AD proxy
> をやりたいと思い試行錯誤しています。
>
> 学認Webサイトの下の記事を拝見し、
> 東京大学様の試行事例がありましたのでそれにならって設定したのですが、おそらくは大変初歩的なところでつまづいています。
>
> 同様のことを試された方、お知恵をいただけますと幸いでございます。
>
> ■参照した資料
> NIIオープンフォーラム2022発表資料
> → "Using SAML Proxying in the Shibboleth IdP to connect with Azure AD"
>
> ■起きている現象
> 上記を参照して設定を行った結果、
> ○Azure AD認証は通った。
> ○次の LDAP 問い合わせのステップで、エラー "opensaml::FatalProfileException"
> →idp.loglevel.ldap=DEBUG に設定して DEBUGログを調べたところ、
> 　LDAP問い合わせフィルタが filter='(id=$resolutionContext.principal)'
> 　つまり $resolutionContext.principal
> がユーザ名に置き換わらず、そのままLDAPサーバへ問い合わせていた。
>
> ■知りたいこと
> ○Azure ADから返される SAML
> レスポンスの内容を確認したいのですが、ログに出力するなどの方法はありますでしょうか。
> ○上記のように置き換わらない原因わかる方がもしもいらっしゃいましたら、教えてください。
>
> ■前提などの補足
> ○当Shibboleth IdP の最初のインストールバージョンは Shibboleth 4.1.4 。
> 　現在のバージョンは 4.3.1
> ○上記の「参照した資料」は V4.0 系が前提のようで一部設定が異なったため、
> 　実際は下記の資料にしたがって設定を行っている。
> 　"Example procedure for adding O365 authentication to Shibboleth"

--

--- 
このグループから退会し、グループからのメールの配信を停止するには xxxxxxxxxxxxxxxxxxxx@xxxxxxxxx にメールを送信してください。