syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: [DISCUSS] - Third party JWT SSO integration?
Date Tue, 27 Jun 2017 11:03:11 GMT
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/

Mime
View raw message