OpenID Connect Federation 入门指南

  1. 云栖社区>
  2. 博客>
  3. 正文

OpenID Connect Federation 入门指南

登高且赋 2017-12-28 16:35:00 浏览1214
展开阅读全文

标准原文OpenID Connect Federation 1.0

OpenID-Connect针对跨域的身份鉴别请求的需求,提出了自己的解决方案——OIDC联盟(OpenID Connect Federation )。和基于SAML框架的eduGAIN不同,OIDC联盟还只停留在技术方案阶段,并没有一个实体团体来维护和推进身份联盟的建设。

本文是基于OpenID-Connect的进阶内容。关于OpenID-Connect的详尽内容,请参看 OpenID Connect 协议入门指南

1. 发现与动态注册

在提出OIDC联盟之前, OpenID-Connect提供了发现Discovery)和动态注册Dynamic Registration)机制来支持服务方(Service Provider, SP)发现未知身份提供方(Identity Provider,IDP)并动态注册,其流程为:

  1. SP从IDP的特定路径中获取IDP的配置信息,如IDP的授权端点(authorization_endpoint)和令牌端点(token_endpoint)、验证ID令牌签名的公钥等;
  2. SP向IDP指定的注册端点发送他的返回重定向(redirect_uri)等信息;
  3. IDP返回的响应包括SP的ID(client_id)和口令(client_secret)等信息。

但是这样IDP动态注册SP的机制存在如下问题:

  1. 接收方不能仅凭消息本身来验证消息的完整性和消息来源的可靠性;
  2. 完整性和消息来源的可靠性保护完全依赖于TLS协议,但是TLS也可能出现问题;

如何才能实现元数据(IDP的配置信息、SP的配置信息)的可靠传输,这便是构建OIDC联盟的初衷。OIDC联盟利用唯一的可信第三方,建立一个互相信任的联盟,用于元数据的可靠传输,元数据的接收方可以验证消息的完整性和来源的可靠性,从而信任这些信息。

OIDC联盟使用OAuth2.0中规定的签名元数据(Signed Metadata),构建元数据声明(metadata statement)来安全传递元数据。

2. 元数据参数(Metadata Parameters)

为了构建联盟参与方的元数据声明,IDP和SP在注册是都需要提供联盟所要求的元数据参数。

以下为OIDC联盟在注册时IDP和SP都可配置的元数据参数:

  1. signing_keys (可选) 联盟中实体的公钥,以JSON Web Key (JWK)形式呈现。与IDP签发ID令牌的公钥不同,该公钥主要用来验证元数据的完整性和来源的可靠性,即对元数据进行验签时使用,如SP对IDP的注册响应的验签。
  2. signing_keys_uri (可选) 获取联盟中实体的公钥的URL,作用和signing_keys相同。唯一不同的是,从URL中获得的signing_keys是单独经过上级实体以 JSON Web Signature (JWS)格式签名的,而signing_keys中的公钥,会和其他元数据参数一起被上级实体签名。
  3. metadata_statements (可选) 联盟规定的元数据是嵌套的元数据,本级元数据需要加上上一级的元数据,直到最终的可信第三方,即信任锚。元数据声明参数的值是上级的元数据。本级的元数据将作为下级的元数据声明的值。最高级(Level 0)的元数据不包含该参数。
  4. metadata_statement_uris (可选)获取元数据声明的URL。
  5. signed_jwks_uri (可选) 增强版的jwks_uri。获取验证ID令牌签名的公钥的URL。公钥经过本机构的私钥签名,接收方可以使用signing_ keys进行验签。
  6. signing_keys需要对以下数据进行签名:下级的签名公钥(signing_ keys)、下级的元数据声明(metadata_statement)、和本级的ID令牌签名公钥(如果是IDP的话)。
  7. federation_usage (可选) 元数据声明的用处。由于发现、动态注册请求和动态注册响应中都会涉及元数据,这些元数据包含的参数并不相同,federation_usage规定了元数据究竟用于发现、动态注册请求还是动态注册响应。该参数的值包括:discoveryregistrationresponse

SP的元数据参数还包括redirect_uris等,本标准还规定了以下专用于SP的参数:

  1. scopes (建议) SP想要的资源范围。
  2. claims (建议) SP想要的属性声明。

IDP的元数据参数还包括issuer、authorization_endpoint、token_end point等。

3. 元数据声明(Metadata Statements)

元数据声明,即元数据参数组成的数据结构。某一机构的元数据声明包含本机构的签名公钥(signing_keys)以及本机构的元数据请求,包含本级的元数据参数。
本机构将未签名的元数据声明发送给上级机构,上级机构使用它的私钥对本机构的元数据请求和签名公钥进行签名,得到经过签名的元数据声明(metadata statement)。本机构的元数据声明将作为下级机构的元数据请求中参数metadata_ statement的值。

{
  "redirect_uris": ["https://example.com/rp1"],
  "metadata_statements": {
    'https://example.com':
      {
        "scope": "openid eduperson",
        "response_types": ["code", "code id_token"],
        "contacts": ["rp_helpdesk@example.com"],
        "redirect_uris": ["https://example.com/rp1"],
        "response_types: ["code"]
        "metadata_statements" : {
          'https://example.com':
            {
              "logo_uri": "https://example.com/logo.jpg",
              "policy_uri": "https://example.com/policy.html",
              "tos_uri": "https://example.com/tos.html"
            }
         }
      }
   }
}

元数据声明,是JWT格式的数据,如上,使用上级机构的私钥签名,JWT数据的载荷为本机构的签名公钥和其他元数据参数。

假设A、B、C是联盟中分属三个层次的机构,A是上级,B是中间级C是下级,则A对B的元参数请求和签名公钥签名,B再对C的元数据请求和签名公钥签名。C的元数据请求应当包含B的元数据声明。第0层的元数据请求不包含元数据声明的参数。第N层的请求者是第N+1层的签名者。

{
  "application_type": "web",
  "exp": 1496130898,
  "iat": 1496044498,
  "iss": "https://www.uninett.no",
  "kid": "5jl-7XNA-LaMiorIlf3qDdk35hbRaxnesdqzg1Q5rcg",
  "metadata_statements": {
    "https://swamid.sunet.se/": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjY1TUp
yRnFDeDBGUjk2SzNxWHJNZ0ZWMTkxOF9fVFc3dnVJMl9MUl9HZ28ifQ.eyJmZWRlcmF0
aW9uX3VzYWdlIjogInJlZ2lzdHJhdGlvbiIsICJzaWduaW5nX2tleXMiOiB7ImtleXMi
OiBbeyJrdHkiOiAiUlNBIiwgInVzZSI6ICJzaWciLCAia2lkIjogIjVqbC03WE5BLUxh
TWlvcklsZjNxRGRrMzVoYlJheG5lc2RxemcxUTVyY2ciLCAibiI6ICIyTmRUbXpNYThw
cWlzZU8wdFNITW1SaU1VbWVhRmQxVUNfLVUwSXJiLTdEUlBZTE92OER2VWRJRTA2OXZu
eURMWlNpM1VpbzNIMkUyNVc1c1FwUjdpZWVHeHI1bDNYWVdKZ2tpcW1EaWtIblF3anRw
RklPM1lfNWd5SHBCZHFLSHpZcnFPaDZhTWRyeUZqWkhqRF9QcDVkaF8tZG5WUjFqbHdB
M0wzSF91WG92QzAwYmVDMzBGUFk4OFByRFl2X1hDYm1KaUhtZ0FFTHlmZ1N2d0lHcUV6
a241VHc0Mk80RVlfaFB6Vm5NYkdSTEl6cy11eUlqSTJKTGpoemdWUDJBZlBkVF9zNkdB
QktmVlBrWDZvQ090enpqbVZfY2EzX2VPUGZ2MVlJQ0xlSnJ5M0pTVnRIbHFSekNDS2wy
ZFdQZC1XY09MN0lNVWlBd3hSV1hkNzFvbVEiLCAiZSI6ICJBUUFCIn1dfSwgInJlc3Bv
bnNlX3R5cGVzIjogWyJjb2RlIiwgInRva2VuIl0sICJ0b2tlbl9lbmRwb2ludF9hdXRo
X21ldGhvZCI6ICJwcml2YXRlX2tleV9qd3QiLCAic2NvcGVzIjogWyJvcGVuaWQiLCAi
ZW1haWwiXSwgImlzcyI6ICJodHRwczovL3N3YW1pZC5zdW5ldC5zZS8iLCAiaWF0Ijog
MTQ5NjA0NDQ5NywgImV4cCI6IDE0OTg2MzY0OTcsICJraWQiOiAiNjVNSnJGcUN4MEZS
OTZLM3FYck1nRlYxOTE4X19UVzd2dUkyX0xSX0dnbyIsICJqdGkiOiAiMWMzOTY0NmM0
MGExNDVkNGFkYWIwMGNlNmQ0MmRhYmMifQ.YPcpHSluei_DbOyRxDQ9PeL5FU23ZHU45
G33WTJlCT1QxqzKLYFjHdm28WVHxquQ4FrgmY49Wt9vm1cvsg5hSyxNcHJMDDL3Y4pfe
LeozTVZhDrx-wUCcPqCIxpU9WdtuWvefyvxzbuF8qMf7_4Aiw8V1TqJc7tqYpd_Ic0xd
uHEMFaF1UATztdGOKy4iISSR6qKOKGfJyW4IlNw-hLR5DImln4W7uikHFUxkKjmrXCQ-
AnKhMUub75dThKg-vIZiXD8T0KbIsi2l40bH_n9qWexnpX_BAGvCgY9LlEJ0Z8wlTpHq
HzD2mrs218ysop2tB45ICJpsW_YDqWHgvP9mQ"
  },
  "response_types": [
    "code"
  ],
  "sub": "https://foodle.uninett.no"
}

4. 信任模型(Trust Model)

OIDC联盟依靠签名公钥(signing_keys),建立起一条一条的信任链,每一条信任链都到达可信第三方(Federation Operator)。

联盟内所有成员都信任Federation Operator。Federation Operator需要公开它的公钥。联盟内成员通过HTTPS网站获得,HTTPS网站的证书应当记录在证书透明化日志中。

最内层的元数据声明由Federation Operator签名,不包含元数据声明这一参数。元数据声明的产生流程:

  1. 本机构将自身所需的元数据参数和签名公钥发送给上级机构。
  2. 本机构可以同时将上级的元数据声明发送给上级机构,也可以由上级机构直接添加,因为本机构的元数据声明当中应当包含上级机构的元数据声明(metadata statement参数的值)。
  3. 上级机构可以自主地添加或者删除某些参数,然后对元数据请求和签名公钥进行签名。
  4. 上级机构将签完名地元数据声明发送给本机构。

元数据声明的验签流程:

  1. 收到一个元数据声明,首先应当解析最内层地元数据声明。利用已知的Federation Operator的公钥验证最内层声明的正确性。
  2. 从最内层声明中提取公钥,验证次内层的声明的正确性。
  3. 以此类推。

发现和动态注册机制保持不变,但是所有的数据都应当是元数据声明。

发现和动态注册请求的参数通常是固定的,因此可以事先由各自的上级机构签完名并存储在本地,然后直接发送给相对方。

动态注册响应的参数一般是不固定的,有两种解决方案:

  1. IDP的上级机构提供实时签名的服务;
  2. IDP自己对响应进行签名:IDP需要事先获得一份只有signing_keys的、经过上级机构签名的元数据声明,然后将该声明嵌套在动态注册响应中,并使用自己的私钥签名。这样的元数据声明也能通过验证。

5. 联盟的加入

OIDC联盟标准允许IDP和SP加入多个OIDC联盟,通过发现和动态注册机制,IDP和SP协商确定彼此认可的联盟。

IDP发布配置信息的时候,可以发布多个元数据声明,各自指向不同的Federation Operator。

SP发起动态注册请求的时候选择其中若干个联盟签发的元数据声明,发送给IDP。
IDP选择其中一个联盟,返回该联盟签发的动态注册响应。

SP向IDP发送的注册请求如下:

{
  "redirect_uris": ["https://example.com/rp2/callback"],
  "metadata_statement_uris": {
      https://swamid.sunet.se/":
        "https://dev.example.com/rp1/idfed/swamid.jws",
      "https://www.incommon.org":
        "https://dev.example.com/rp1/idfed/incommon.jws"
  }
}

IDP响应SP的注册信息如下:

{
  "client_id": "abcdefgh",
  "client_secret": "0123456789",
  "client_id_issued_at": 1462375583,
  "client_secret_expires_at": 1462379183,
  "redirect_uris": ["https://example.com/rp2/callback"],
  "metadata_statement_uris": {
    "https://swamid.sunet.se/":
      "https://dev.example.com/rp1/idfed/swamid.jws",
  }
}

参考文件

  1. OAuth 2.0 Authorization Server Metadata
  2. JSON Web Key (JWK)
  3. JSON Web Signature (JWS)

网友评论

登录后评论
0/500
评论
登高且赋
+ 关注