1. 技术文章
  2. How to configure MIcrosoft JWT with symmetric key?

How to configure MIcrosoft JWT with symmetric key?

由 試著忘記壹切 提交于 2019-11-28 19:32:49

Update 2014/02/13:

As @leastprivilege points out below, this is a whole lot easier with the RTM version of the JWT. I strongly suggest that you ignore this and go with the example he provides at http://leastprivilege.com/2013/07/16/identityserver-using-ws-federation-with-jwt-tokens-and-symmetric-signatures/.

Note that the original answer below was for the Beta version, Microsoft.IdentityModel.Tokens.JWT. Upgrading to the release version, System.IdentityModel.Tokens.Jwt, required just a little more work. See below.

The primary problem turns out to be that the method JWTSecurityTokenHandler.ValidateToken(token) does not fully populate the TokenValidationParameters that it passes to JWTSecurityTokenHandler.ValidateToken(token, validationParameters). In particular, it doesn't populate the SigningToken member or the ValidIssuers (or ValidIssuer).

Interestingly, the configuration I showed in my original question actually is loaded by the token resolver, and is available at runtime, as you can see in the code below.

I don't know how to specify the valid issuer string in the configuration file, though. I strongly suspect that there's a place to put that info, but I haven't yet figured out where it belongs.

The solution to my problem is to create a custom security token handler that derives from JWTSecurityTokenHandler. Overriding ValidateToken(token, validationParameters) gives me the opportunity to set those parameters that I need, and then call the base class's ValidateToken method.

public class CustomJwtSecurityTokenHandler: JWTSecurityTokenHandler
{
    // Override ValidateSignature so that it gets the SigningToken from the configuration if it doesn't exist in
    // the validationParameters object.
    private const string KeyName = "https://localhost/TestRelyingParty";
    private const string ValidIssuerString = "https://mySTSname/trust";
    public override ClaimsPrincipal ValidateToken(JWTSecurityToken jwt, TokenValidationParameters validationParameters)
    {
        // set up valid issuers
        if ((validationParameters.ValidIssuer == null) &&
            (validationParameters.ValidIssuers == null || !validationParameters.ValidIssuers.Any()))
        {
            validationParameters.ValidIssuers = new List<string> {ValidIssuerString};
        }
        // and signing token.
        if (validationParameters.SigningToken == null)
        {
            var resolver = (NamedKeyIssuerTokenResolver)this.Configuration.IssuerTokenResolver;
            if (resolver.SecurityKeys != null)
            {
                List<SecurityKey> skeys;
                if (resolver.SecurityKeys.TryGetValue(KeyName, out skeys))
                {
                    var tok = new NamedKeySecurityToken(KeyName, skeys);
                    validationParameters.SigningToken = tok;
                }
            }
        }
        return base.ValidateToken(jwt, validationParameters);
    }
}

In my Web.config, I just had to change the security token handler:

  <securityTokenHandlers>
    <!--<add type="Microsoft.IdentityModel.Tokens.JWT.JWTSecurityTokenHandler,Microsoft.IdentityModel.Tokens.JWT" />-->
    <!-- replaces the default JWTSecurityTokenHandler -->
    <add type="TestRelyingParty.CustomJwtSecurityTokenHandler,TestRelyingParty" />

Nothing like spending three or four days researching a problem that is solved with a couple dozen lines of code . . .

Addition for new version

In June of 2013, Microsoft officially released their JWT. They changed the namespace to System.IdentityModel.Tokens.Jwt. After upgrading to that, the solution above stopped working. To get it working, I had to add the following to my CustomJwtSecurityTokenHandler. That's in addition to the existing code.

public override ClaimsPrincipal ValidateToken(JwtSecurityToken jwt)
{
    var vparms = new TokenValidationParameters
        {
            AllowedAudiences = Configuration.AudienceRestriction.AllowedAudienceUris.Select(s => s.ToString())
        };
    return ValidateToken(jwt, vparms);
}

Here is a usage example of this library with .Net 4.5 that issues and validates a JWT signed with symmetric key based HMAC SHA256 (all in code and without WIF):

string jwtIssuer = "MyIssuer";
string jwtAudience = "MyAudience";

// Generate symmetric key for HMAC-SHA256 signature
RNGCryptoServiceProvider cryptoProvider = new RNGCryptoServiceProvider();
byte[] keyForHmacSha256 = new byte[64];
cryptoProvider.GetNonZeroBytes(keyForHmacSha256);

///////////////////////////////////////////////////////////////////
// Create signing credentials for the signed JWT.
// This object is used to cryptographically sign the JWT by the issuer.
SigningCredentials sc = new SigningCredentials(
                                new InMemorySymmetricSecurityKey(keyForHmacSha256),
                                "http://www.w3.org/2001/04/xmldsig-more#hmac-sha256",
                                "http://www.w3.org/2001/04/xmlenc#sha256");

///////////////////////////////////////////////////////////////////
// Create token validation parameters for the signed JWT
// This object will be used to verify the cryptographic signature of the received JWT
TokenValidationParameters validationParams =
    new TokenValidationParameters()
    {
        AllowedAudience = s_jwtAudience,
        ValidIssuer = s_jwtIssuer,
        ValidateExpiration = true,
        ValidateNotBefore = true,
        ValidateIssuer = true,
        ValidateSignature = true,
        SigningToken = new BinarySecretSecurityToken(keyForHmacSha256),
    };

///////////////////////////////////////////////////////////////////
// Create JWT handler
// This object is used to write/sign/decode/validate JWTs
JWTSecurityTokenHandler jwtHandler = new JWTSecurityTokenHandler();

// Create a simple JWT claim set
IList<Claim> payloadClaims = new List<Claim>() { new Claim("clm1", "clm1 value"), };

// Create a JWT with signing credentials and lifetime of 12 hours
JWTSecurityToken jwt =
    new JWTSecurityToken(jwtIssuer, jwtAudience, payloadClaims, sc, DateTime.UtcNow, DateTime.UtcNow.AddHours(12.0));

// Serialize the JWT
// This is how our JWT looks on the wire: <Base64UrlEncoded header>.<Base64UrlEncoded body>.<signature>
string jwtOnTheWire = jwtHandler.WriteToken(jwt);

// Validate the token signature (we provide the shared symmetric key in `validationParams`)
// This will throw if the signature does not validate
jwtHandler.ValidateToken(jwtOnTheWire, validationParams);

// Parse JWT from the Base64UrlEncoded wire form (<Base64UrlEncoded header>.<Base64UrlEncoded body>.<signature>)
JWTSecurityToken parsedJwt = jwtHandler.ReadToken(jwtOnTheWire) as JWTSecurityToken;
Brent Schmaltz

Jim,

Thanks for trying out the preview, sorry that you had some issues that weren't obvious :-(.

The NamedKeyIssuerTokenResolver was born from two ideas:

  1. the need to associate a key for checking the signature that is a shared secret;
  2. multiple valid keys could be in use at the same time.

It was designed to work with the NamedKeySecurityToken that has a name and a number of keys. The NKITR can return a NKST which simplifies checking a signature when multiple keys are in play.

One goal for the NKITR was to provide a mapping between the JWT iss claim (in the header) and a key. When it's time to check the signature, the JWTHandler checks:

  1. TokenValidationParamerter.SigningToken, if found use it;
  2. A SecurityKeyIdentifier obtained from JWT.Header.SigningKeyIdentifier (currently only x5t is supported) is sent to the current INR;
  3. A NamedKeyIdentifierClause is created from the Jwt.Issuer and sent to the current INR.

Since a SecurityToken can contain multiple keys, each one in order is used to check the signature, first success stops and the JWT.SigningToken will contain the SecurityToken that validated the signature.

Jim and Willy,

Sorry about the confusion with the ValidateToken(SecurityToken) overload method. Parameters are moved from Configuration to ValidationParameters, but not the properties like ValidIssuer that have a single item, but

IssuerNameRegistry -> VP.IssuerNameRegistry
IssuerTokenResolver -> VP.SigningTokenResolver
AllowedAudienceUris -> VP.AllowedAudiences
CertificateValidator -> VP.CertificateValidator
SaveBootStrapContext -> VP.SaveBootStrapContext

Brent

AFAIK, the JWtSecurityTokenHandler is not yet ready to be used from a configuration file. The example given by Vittorio Bertocci is also a "code example". In that, he explicitly calls the overloaded ValidateToken with the additional tokenValidationParameters parameter that contains all stuff needed to do the validation (like the symmetric key).
Unfortunately, that overload is not called by the normal Wif pipeline (it calls the ValidateToken with just the token as a parameter) I resolved to subclassing the jwtsecurity token handler, override LoadCustomConfiguration to manually load the stuff needed to create a tokenValidationParemeter object (I had to create some configuration objects for this). Then I did an override of validateToken to explictly call the overload with the additional parameter (which I could create on the fly with the parameters I read from the config). All very cumbersome to do but the only way to tap into the power of the tokenValidationparameters. (but I might be wrong of course)

  <issuerTokenResolver type="Microsoft.IdentityModel.Tokens.JWT.NamedKeyIssuerTokenResolver, Microsoft.IdentityModel.Tokens.JWT">
    <securityKey symmetricKey="01234567890123456789012345678901" name="MyIssuer"/>
  </issuerTokenResolver>
  <securityTokenHandlers>

Here is how it works with the RTM version of the JWT handler: http://leastprivilege.com/2013/07/16/identityserver-using-ws-federation-with-jwt-tokens-and-symmetric-signatures/

标签
.net
wif
jwt
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!