You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2017/06/26 16:07:56 UTC
[DISCUSS] - Third party JWT SSO integration?
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.
WDYT?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] - Third party JWT SSO integration?
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 27/06/2017 16:05, Colm O hEigeartaigh wrote:
> Hi Francesco,
>
> On Tue, Jun 27, 2017 at 9:24 AM, Francesco Chicchiriccò <il...@apache.org> wrote:
>
>> 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.
> +1 - please do!
>
>> 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.
> Yep that's fine.
>
>> 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.
> No rush from my POV. Let's get it into JIRA anyway so that we can track it.
Agree: would you mind to do that? Thanks!
Regards.
> [1] https://github.com/apache/syncope/blob/2_0_X/core/logic/src/
> main/java/org/apache/syncope/core/logic/init/ClassPathScanI
> mplementationLookup.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/d8a6f8fe3629d1d00165e24
> 61458511d8ace983af6006a5d304fa6a9@%3Cuser.syncope.apache.org%3E
> [4] https://lists.apache.org/thread.html/7d9072146f01994c8fb7f02
> c8af1f88e031345e391c06970a8fcf1ff@%3Cuser.syncope.apache.org%3E
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: [DISCUSS] - Third party JWT SSO integration?
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Francesco,
On Tue, Jun 27, 2017 at 9:24 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> wrote:
> 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.
>
+1 - please do!
>
> 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.
>
Yep that's fine.
>
> 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.
>
No rush from my POV. Let's get it into JIRA anyway so that we can track it.
Colm.
>
> Regards.
>
> [1] https://github.com/apache/syncope/blob/2_0_X/core/logic/src/
> main/java/org/apache/syncope/core/logic/init/ClassPathScanI
> mplementationLookup.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/d8a6f8fe3629d1d00165e24
> 61458511d8ace983af6006a5d304fa6a9@%3Cuser.syncope.apache.org%3E
> [4] https://lists.apache.org/thread.html/7d9072146f01994c8fb7f02
> c8af1f88e031345e391c06970a8fcf1ff@%3Cuser.syncope.apache.org%3E
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] - Third party JWT SSO integration?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/
Re: [DISCUSS] - Third party JWT SSO integration?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>
>
Re: [DISCUSS] - Third party JWT SSO integration?
Posted by Francesco Chicchiriccò <il...@apache.org>.
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
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/