[upki-fed:213] RE: [upki-fed:209] Re: UPKIフェデレーションの属性追加について

["OZAKI Koji" <xxxxx@xxxxxxxxxxxxxxxxxxx>]

京都産業大学の尾崎です。
皆様，色々とご検討くださりありがとうございます。

＃長文，乱文，御容赦ください。後半を書いて，前半はもはや不要かと思ったの
＃ですが，折角なのでそのまま送ります。

> 岡部です。
> 
> 「全国規模の一元的なシステムはやらない方が全体として安全」というご指摘に
> は同感です。UPKIの最初の頃に日本全体の認証基盤をどういうアーキテクチャに
> するかいろいろな可能性を考えましたが、少なくともＮＩＩに集中させるような
> のはあり得ないと確信しました;)

確かに情報が集中すると狙われるのは世の常ですので，その判断は理解できます。

ただ，Shibbolethのアーキテクチャであれば，情報を持っているのはIdPですから
狙われるのはIdP（の後ろにいるLDAP等のデータ）だと考えます。

日本全体の認証基盤をNIIに集中させることによる危険性とは
１．全体のアーキテクチャをShibbolethに（単一に）誘導してしまう
２．NIIのDSが侵入される
という２点でしょうか。

１．については，ShibbolethのIdPが多くなることで，このIdPが狙われ易くなること
は想像されますが，これを否定することは学認の存在自体失われると思います。
＃それに，学生証番号を持つ，持たないという議論以前の問題ですし。

２．について，DSが侵入された結果，IdPの情報が攻撃される可能性があるかどうか。
メタデータは偽者をIdPやSPに更新させることができるので，攻撃者が仕立てたIdP
をフェデレーションに参加させることで，SPを不正利用することは可能でしょう。
ただ，いち利用者としての利用ですから，情報が流出するような事案にはならない
と思われますし，やはりIdPに学生証番号を持つかどうかには関係ありません。
不正なSPが参加した場合も，そのSPに属性を提供しなければ済む話であり，SPをホワ
イトリスト的に登録していれば大丈夫でしょう。少なくとも学生証番号の属性を無制
限に提供する設定をIdPに定義することはないでしょうから大丈夫なのかな，と思いま
す。

＃SAMLの知識が不十分なまま記述していますので，間違っているかもしれません。
＃ご指摘ください。

> ただ一方で、Shibbolethのようなフェデレーションは大学間だけでなく大学内で
> も用いられうるものであり（京大では実際そうしています）、そこで職員番号・
> 学生番号のようなデータをやりとりすることはアリだと思います。もちろんその
> 場合には大学で閉じた属性を使ってもいいわけですが、尾崎さんの提案のように
> 学認としての共通属性を決めておいて必要なときにはそれを使うことは、設定情
> 報の互換性の点でメリットがあります。もちろん、攻撃者に対してはどの属性名
> でどういう情報が入っているかのヒントを与えるというセキュリティ上のマイナ
> ス面もありトレードオフではありますが。

１．統一属性を決める
２．SP毎に属性を決める。各IdPはそれに合わせて（変換して）属性を送る
のどちらかだと思います。統一属性を持つ視点で書くと

【メリット】
・IdPの記述を説明しやすい（スキーマも含めて）
・SPの記述（利用方法例）を説明しやすい
・オープンソース的なSPが出来た時（フェデレーション経由でなく，自大学SPで
　動かすようなもの），そのまま設置するだけで動作する

【デメリット】
・セキュリティ上のマイナスがある
・SP毎にOIDを振る必要がある

このような所でしょうか。

と，ここまで書いてふと思ったのですが，やりとりに使われる重要な定義はOIDだけ
なので，OIDさえ共通に定義しておけばいいのではないかと。セキュリティ上狙われ
やすいのはSPでの変数名でしょうから，受け取る際に名前を変えて受け取ればいい
のではないでしょうか。

mail属性を例にすると，このように。

名前：mail
oid ：0.9.2342.19200300.100.1.3

■IdP側：attribute-resolver.xml
    <resolver:AttributeDefinition id="mail" ★（※Ａ）
        xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
        sourceAttributeID="e-mail"> ★（※１）
        <resolver:Dependency ref="myLDAP" />

        <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:mace:dir:attribute-def:mail" />

        <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:oid:0.9.2342.19200300.100.1.3" ★（※２）
            friendlyName="mail" />
    </resolver:AttributeDefinition>

■IdP側：attribute-filter.xml
        <AttributeRule attributeID="mail"> ★（※Ｂ）
            <PermitValueRule xsi:type="basic:ANY" />
        </AttributeRule>

■SP側：attribute-map.xml
<Attribute name="urn:oid:0.9.2342.19200300.100.1.3" id="denshimail" /> ★（※３）

「※１」のLDAP属性で管理されているメールアドレスが，「※２」のOIDで送信
され，「※３」で同じOIDを指定して別の名前で受け取る。「mail」という名前
は「※Ａ」「※Ｂ」でさえ一致していれば別のものでも大丈夫（IdP内で完結）。



きちんと受け取れることは実験しました。friendlyNameがどこで使われている
のか理解していないので，ダメな実装なのかもしれませんが…

---------------
京都産業大学　情報センター　尾崎　孝治