Sorry, missed the point, the idea was to use an issuer to get the right
verifier in case of JWS, which would use the issuer-specific key material ?
Just FYI, JwsJwtConsumer (this one differs from JoseJwtConsumer is that
it only supports the signature validation) will return
JwtToken/JwtClaims (still unvalidated - JWS format allows to introspect
a JWS payload by any 3rd party JWS library as opposed to JWE), with
getIssuer() then used to load the right JwsSignatureVerifier.
If the token contains 'kid' of the key (in its JwsHeaders) then it can
be used to load JwsSignatureVerifier too though the producer will need
to know the 'kids' so Colm is right using the issuers will be more
flexible...
Sorry for the noise in case the above is not relevant :-)
Sergey
On 27/06/17 10:05, Sergey Beryozkin wrote:
Hi Francesco
I'm not sure it can help but a utility class JoseJwtConsumer will return
a verified (and/or decrypted) JwtToken which has the typed methods like
getIssuer, etc...
JoseJwtConsumer will itself create JwsSignatureVerifier (and/or
JweDecryptionProvider) (using the endpoint contextual properties) and
use them to prepare JwtToken for the application code.
Cheers, Sergey
On 27/06/17 09:24, Francesco Chicchiriccò wrote:
On 26/06/2017 18:07, Colm O hEigeartaigh wrote:
Hi all,
It occurred to me that we can easily support SSO using third party JWT
tokens. Instead of (or as well as) having a single
"jwsSignatureVerifier"
in securityContext.xml, we could have a map of issuer ->
jwsSignatureVerifier Objects.
We could get the verifier to use to verify the signature by querying the
map using the issuer of the token. If this succeeds, and if the
subject is
a known user, we could allow the call to proceed.
Alternatively, we could have a separate service which translates third
party JWT tokens into local SSO tokens.
Hi Colm,
your idea seems interesting.
Instead of providing a map in securityContext.xml, I would rather
enable [1] to dynamically discover JwsSignatureVerifier
implementations (or maybe a new interface of ours extending that,
adding a getIssuer() method).
Moreover, the new interface extending JwsSignatureVerifier could also
provide a method to resolve the JWT subject into Syncope username
(known user).
If you like, I can take care of this.
Please also note that such SSO would work only at REST level; in order
to enable Admin Console or Enduser UI to that, something like the SAML
2.0 SP Agent [2] will need to be provided.
As people started asking for 2.0.4 [3][4] and CXF 3.1.12 is under
vote, I think we should start finalizing, e.g. postponing new features
and improvements to 2.0.5. But maybe this one can still fit.
Regards.
[1]
https://github.com/apache/syncope/blob/2_0_X/core/logic/src/main/java/org/apache/syncope/core/logic/init/ClassPathScanImplementationLookup.java
[2]
https://github.com/apache/syncope/blob/2_0_X/ext/saml2sp/agent/src/main/java/org/apache/syncope/ext/saml2lsp/agent/AssertionConsumer.java#L47
[3]
https://lists.apache.org/thread.html/d8a6f8fe3629d1d00165e2461458511d8ace983af6006a5d304fa6a9@%3Cuser.syncope.apache.org%3E
[4]
https://lists.apache.org/thread.html/7d9072146f01994c8fb7f02c8af1f88e031345e391c06970a8fcf1ff@%3Cuser.syncope.apache.org%3E
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
