使用带有委托的JWT令牌(ActAs)

Question

我使用WIF和.NET 4.5实现了一个基于索赔的身份验证系统的工作实现。它包含了通常的部分：

• 带有被动端点和主动端点的自定义STS
• 后端WCF服务
• 前端MVC应用程序
• 前端WebApi应用程序

前端应用程序对backedn WCF服务的调用使用委托身份验证，因此用户在前端应用程序中进行身份验证，应用程序使用ActAs=BootstrapToken请求一个新的令牌，然后调用WCF服务。

所有这些都可以正确地使用SAML令牌。

现在我想使用JWT令牌与WebApi对话，所以我在我的STS和WebApi项目中安装了用于MicrosoftWebFramework4.5的 Nuget包。

因此，我的STS正确地发出了签名的JWT令牌，我的WebApi依赖方验证了相同的令牌。都很好。

问题：

如果我在我的RST的ActAs字段中使用JWT令牌，它将在没有签名的情况下被发送给，因此它自然会被STS拒绝。似乎SecurityTokenHandler.ReadToken()方法返回的令牌没有任何签名信息。

现在我的困境是:这是一个支持JWT令牌的场景吗？据我所知，JWT令牌并不包含验证签名的所有信息，而不是SAML令牌，因此还有其他限制吗？

另一方面，如果这一点确实得到支持，是否有人在此之前实施过，或有任何想法？这是一个开发人员预览，那么它会是一个bug吗？

编辑

这是一个例子来说明这个问题。在STS (访问签名密钥)和依赖方(访问证书的公钥)中运行时，代码产生相同的结果：

System.Diagnostics.Debug.WriteLine("Raw Token       : {0}", (object)rawToken);

var readToken = this.identityConfiguration.SecurityTokenHandlers.ReadToken(rawToken);

this.identityConfiguration.SecurityTokenHandlers.ValidateToken(readToken);

var serializedToken = this.identityConfiguration.SecurityTokenHandlers.WriteToken(readToken);

System.Diagnostics.Debug.WriteLine("Serialized Token: {0}", (object)serializedToken);

生成以下内容

Raw Token       : eyJAi(...)x3a9.eyJvYXB(...)DYzWiJ9.y-lT(...)PyBUTw
Serialized Token: eyJAi(...)x3a9.eyJvYXB(...)DYzWiJ9.

因此，很明显，读/写往返会丢失签名信息。我能理解为什么这发生在RP中，而不是在STS中。

编辑2

下面是当前的JWTSecurityTokenHandler.WriteToken(SecurityToken token)实现：

public override string WriteToken(SecurityToken token)
{
    Utility.VerifyNonNullArgument("token", token);
    JWTSecurityToken jWTSecurityToken = token as JWTSecurityToken;
    if (jWTSecurityToken == null)
    {
        throw new SecurityTokenException(string.Format(CultureInfo.InvariantCulture, "JWT10200: This instance of JWTSecurityTokenHandler can only write SecurityTokens of type '{0}', a SecurityToken of type '{1}' was received.", new object[]
        {
            typeof(JWTSecurityToken),
            token.GetType()
        }));
    }
    string text = string.Empty;
    string text2 = string.Format(CultureInfo.InvariantCulture, "{0}.{1}", new object[]
    {
        jWTSecurityToken.EncodedHeader,
        jWTSecurityToken.EncodedPayload
    });
    if (jWTSecurityToken.SigningCredentials != null)
    {
        text = this.Sign(text2, jWTSecurityToken.SigningCredentials);
    }
    return string.Format(CultureInfo.InvariantCulture, "{0}.{1}", new object[]
    {
        text2,
        text
    });
}

通过对它的研究，很明显，书面标记在RP中永远不会有它的签名，因为我们没有签名凭证。所以这看起来不像一个bug，而是一个实现决定。我只是不明白为什么。

谢谢

Answer 1

这既不是安全(或任何其他)错误，也不是实现决定。唯一能够生成带有签名的JWT的位置写是发出点。除了令牌发行者之外，任何一方都不应该试图重新创建它(这就是您所说的读写往返)。当您收到一个签名的JWT时，您只能验证和读取它。您可以自由地重新传输原来的JWT，但是您将无法“正确”地重构它，因为您不是发行者，也没有适当的签名密钥。

这就是签署令牌的原因:只有原始发行者才能正确地签名。

如果您愿意，我可以尝试使用安全令牌和STS帮助您设计正确的场景，但为此，请共享您正在实现的场景的序列图。

Answer 2

如果这是一个bug，我不会感到惊讶- JWT处理程序仍然处于预览模式。

但是，也许您不想对Web服务执行ActAs的全部打击--在这里看一看：

http://blogs.msdn.com/b/vbertocci/archive/2013/01/09/using-the-jwt-handler-for-implementing-poor-man-s-delegation-actas.aspx

Answer 3

看看JWTSecurityToken.RawData。包含原始encodedToken的。并且应该有原始发行人的签名。