用于ACS JWT令牌的Exchange IP-STS JWT令牌

时间:2012-12-02 23:39:04

标签: security azure wif acs jwt

我有一个天蓝色的ACS服务,它信任IP-STS 对于活动场景,我首先使用用户名,密码凭据从我的IP-STS获取JWT令牌。有Oauth2端点,一切都很好。 是否可以为我的azure ACS发出的JWT令牌“交换”此IP-STS令牌?如果是这样,是否有代码执行此操作的示例。 (更糟糕的是,我的所有代码都是用JavaScript(实际上是TypeScript),但这并不重要。)

更新: 我正在研究ACS OAuth2草案13终点的提示 我按以下步骤操作:我要求我的自定义STS(ThinkTecture STS)为“ACS OAuth2 draft 13端点”领域提供JWT令牌。这需要一个oAuth客户端ID和秘密,它们在TT STS中是全局的,我认为它们是无关紧要的。在TT STS管理中,我有一个为这个领域配置的对称密钥:key1。我收到了3部分的JWT令牌。令牌上的签名确实是用key1完成的。 然后,我将此令牌传递给ACS,其客户端ID和密码来自服务标识和指定的参数

var form = new FormUrlEncodedContent(new Dictionary<string, string>
{
  { "grant_type", "http://oauth.net/grant_type/jwt/1.0/bearer" },
  { "assertion", rawtoken (the header dot body dot signature form TT STS },
  { "scope", "http://localhost"}
});

不幸的是我现在得到了 {“error”:“invalid_client”,“error_description”:“ACS50027:JWT令牌无效。\ r \ nTrace ID:b107cda5-393b-4b50-b14a-ebaa0ac41913 \ r \ n时间戳:2012-12-05 08:58: 10Z“}

我知道JWT处于测试阶段,因此尚未记录ACS50027。困难的部分是没有已知的方法来调试它。谢谢你的帮助。

3 个答案:

答案 0 :(得分:2)

这绝对是可能的,但我认为任何现有的ACS样本都不会这样做,因此您处于未知领域。

我建议的方法是使用ACS OAuth2 draft 13端点(如this sample中所示,但JWT代替SAML和IdP而不是服务标识)。请求将类似于:

grant_type = http://oauth.net/grant_type/jwt/1.0/bearer& assertion =(JWT)&amp; scope =(RP realm)。

您需要JWT的发行者与您的注册身份提供者以及相关的签名密钥相匹配,以及根据需要传递或更改任何声明的规则以及具有JWT令牌类型的RP。

答案 1 :(得分:0)

好的,我终于找到了办法。你的提示对成功至关重要。 (非常)棘手的部分是IP-STS使用对称密钥来签署JWT令牌。我不得不以编程方式(使用odata api)将此密钥插入Identity提供商下的ACS后台。 (管理控制台不会在任何地方显示此密钥)一切都很接近。唯一的麻烦是ACS从原始令牌复制了受众(“aud”),而我为不同的受众(“范围”)请求了令牌。有什么想法吗?

答案 2 :(得分:-1)

不, 您无法在ACS中交换令牌。唯一可行的方法是,如果您能够将您的IP-STS注册为ACS中的IdP(如果您的IP-STS支持WS-TRUST协议,您将能够这样做)。这会让你陷入被动场景。

唯一可能的活动方案方法是使用Service Identities的用户名/密码身份验证直接从ACS获取JWT令牌。管理ACS中的服务标识不是管理ASP.NET成员资格提供程序,而是具有Management API

使用服务标识进行身份验证的可能方法是密码,对称密钥,X.509证书。因此,如果您对原始IP-STS进行了足够的扭曲,并在其JWT令牌中为您提供了对称密钥作为声明,您将能够使用使用该对称密钥进行身份验证的服务标识从ACS获取JWT令牌。

但是,如果您已经有一个JWT令牌,为什么还需要ACS的另一个?

<强>更新

嗯,声明转换只是“被动”模式中的选项。对于主动模式,唯一的方法(我知道)是使用服务标识,因此没有声明转换。

Passive的问题在于,出于安全原因,ACS将创建一个隐藏的POST表单,以便将提交转换的令牌POST提交给您的依赖方应用程序(RP)。所以没有办法主动获得被动行为。你只能为了审判而做什么,而且由于隐藏形式的被动POST会失败,如下所示: 如果您愿意进行实验(我没有测试过,而且我完全没有意识到结果),您可以尝试模拟提供原始JWT令牌的wsignin1.0操作。您可以查看WS-Federation Passive Requestor Profile,第3.1节,了解如何构建登录请求。您还可以使用Fiddler来完全跟踪被动方案事件链。您将尝试重建的那个是从注册的IdP返回到ACS的wsignin1.0请求。

在某些时候,您将获得包含FORM元素的结果HTML。该表单将包含两个隐藏字段 - wa,其值为wsignin1.0wresult将包含URL编码<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">....这就是您想要的。

如果您成功从IdP重新创建到ACS的原始SignIn请求,那么这将起作用。