[mitreid-connect] Keystore

[Luiz Omori]

Github issue submitted: 'kid' field not present in the access_token #899

Regards,
Luiz

From: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Date: Friday, August 28, 2015 at 5:17 PM
To: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Keystore

Sorry, yes RO==RS in my email.

And there is the kid for the encryption too, eh? https://tools.ietf.org/html/rfc7516#section-4.1.6

Introspection indeed…

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Friday, August 28, 2015 at 4:55 PM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Keystore

I’m assuming by “RO” here you actually mean “RS”, resource server. I’m going to answer based on that, so correct me if I’m wrong. :)

If the AS isn’t including the kid in the access token, then that’s a bug (and a simple one to fix). If that’s the case, please file an issue on GitHub and we’ll roll that into a future patch release. The ID token and access token might be signed with different keys (they usually aren’t in MITREid Connect, but nothing says they have to be signed with the same key in the spec).

As the RS, you can also just do token introspection if you like, avoiding parsing the token entirely.

 — Justin

On Aug 28, 2015, at 3:34 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Thanks, that’s what I thought about the possibility of multiple “use”: “sig”.  But then, here is the question: let’s say I’m the Resource Owner and I got a request which presumably only contains the access_token. Without the ID token we don’t know the kid? Currently we do verify the signature at the RO and we are using the well-known->jwk call to retrieve the IdP PK. If in addition to that I need to configure the name of the key on the RO side as well that would be just slightly better than storing the signing PK itself on the RO and save a few well-known->jwk requests.

Regarding the error, what do you mean? It happened within MitreID itself. We should be using whatever MitreID is configured for and the library version is defined in the POM. Oh, we are still on 1.1.16, haven’t tried the latest.

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Friday, August 28, 2015 at 2:48 PM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Keystore

The “kid” field is what differentiates the keys when there are multiple ones there. I suppose you *could* just look at all the keys and pick whichever one is set up for “use:sig”, but then what do you do if you’ve got multiple “use:sig” keys and you need to sign something? Better to use an explicit identifier, which MITREid Connect requires in its keystores for this purpose. Also, OIDC requires the use of the “kid” field in the ID token to indicate which key was used to sign the token if there are more than one to choose from in the JWK set:

http://openid.net/specs/openid-connect-core-1_0.html#Signing

We currently only support one signing key at a time (and only one encryption key for that matter), but multiple can be in the store and published. The JWK endpoint will publish all available public keys in the keystore. The public keys are generated by reading the public/private keypairs and stripping out the private key information, as you discovered.

The “defaultSigningAlgorithm” property does not select the key, it selects the signature algorithm applied to server-signed objects (like ID tokens) if there isn’t one specified by the client’s specific configuration.

As for the error, it looks like our underlying JOSE library is perhaps too strict in its parsing, so you may want to file a bug on their end. However, none of our production systems have used the “use” field.

 — Justin


On Aug 28, 2015, at 2:09 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Hi,

One minor thing, but that surprisingly is generating quite a few emails internally, is indirectly related to the configuration below (crypto-config.xml):

<bean id="defaultsignerService" class="org.mitre.jwt.signer.service.impl.DefaultJWTSigningAndValidationService">
<constructor-arg name="keyStore" ref="defaultKeyStore" />
<property name="defaultSignerKeyId" value="rsa1" />
  <property name="defaultSigningAlgorithmName" value="RS256" />
</bean>

Question: can “use”: “sig” (as defined in https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41) be used as discriminator for the signing key? In other words, why use the key ID and algorithm?

If multiple keys with “use”: “sig” may be present, how does the client know which one returned from "jwks_uri":"http://localhost:8080/ldap-openid-connect-server/jwk” (from well-known endpoint) should be used? We’ve noticed that that endpoint seems to be returning all keys (we haven’t tested other private keys but at least for the one used for signing the private modulus is removed, as expected).

Regards,
Luiz
_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
http://mailman.mit.edu/mailman/listinfo/mitreid-connect


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150831/95c23685/attachment-0001.html