Hi Francesco,

sure I only meant to refer to that fact (JWT is plain JSON) to clarify why specific JWT claims such as the 'exp' one are not enforced at the generic signature validation level, there the verifier is simply not understanding the structure of the protected payload, it is operating on a byte stream. (to clarify that some extra steps will need to be taken at the higher level in Syncope)

Sorry, I did not really mean to start 'teaching' what JWT was :-)

By the way, having said the above, I just wonder if we should enhance in CXF the helpers which help hiding the way JWT is read/validated with the optional validation logic of the well-known claims.

For example, this helper can validate and decrypt first if needed:

https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwt/JoseJwtConsumer.java

It even has a ttl and a clockoffset properties but these are only enforced at the higher-level, example, here:
https://github.com/apache/cxf/blob/master/rt/rs/security/sso/oidc/src/main/java/org/apache/cxf/rs/security/oidc/rp/OidcClaimsValidator.java#L94

I just wonder if the latter can be done at the JoseJwtConsumer level, I'll think about it...

Sorry for hijacking the thread, but hope it helped to clarify what I was
trying to say earlier

Cheers, Sergey
On 14/06/17 09:31, Francesco Chicchiriccò wrote:
On 13/06/2017 17:58, Colm O hEigeartaigh wrote:
I'll look into adding some tests as well.

Thanks Colm.

@Sergey: I know JWT is "simply" JSON with some rules; I was meaning that we also use CXF to sign and verify signature. Anyway, adding tests to ensure that we properly use the CXF primitives to build Syncope authentication (via Spring Security) is good anyway.

Regards.

On Tue, Jun 13, 2017 at 4:53 PM, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

Hi Francesco
On 13/06/17 16:28, Francesco Chicchiriccò wrote:

On 13/06/2017 17:25, Colm O hEigeartaigh wrote:

Thanks Francesco, I will take care of that.
Cool :-)

Another question - do we have tests (e.g. bad signature, untrusted signature, token expired etc.)?
No, we don't have specific tests for that: since we're using CXF
libraries for parse and generation, I thought it was not necessary,

JWT token is simply a JSON object where each top-level property is called
a 'claim' :-) and given that CXF JOSE (and other JOSE) libraries protect
the arbitrary format payloads, it does not specifically validate the expiry
date, only that the signature or encryption has been done right.
The expiry dates are checked in scope of the higher-level applications
which use JWT, in OIDC for example, so indeed, as Colm indicated, it can be a good idea to test that for example, a JWT token used in scope of Syncope
flows is not effective after it has expired, etc

Thanks, Sergey

but feel free to add.
Regards.

On Tue, Jun 13, 2017 at 4:21 PM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

On 13/06/2017 17:17, Colm O hEigeartaigh wrote:
Hi all,
The docs state that "X-Syncope-Token is returned on response to
successful
authentication
<https://syncope.apache.org/docs/reference-guide.html#rest-
authentication-and-authorization>,
and contains the unique signed JSON Web Token
<https://en.wikipedia.org/wiki/JSON_Web_Token> identifying the
authenticated user".

However with, e.g. curl -I -u alice:security
http://localhost:8080/syncope/rest/users/self I don't see the
X-Syncope-Token header being returned (Syncope 2.0.4-SNAPSHOT).

Do I need to explicitly configure returning the token or am I missing
something else?

The endpoint for obtaining the JWT is
POST /accessTokens/login

Maybe it is an idea to add an example to that section in the docs.

Regards.



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Reply via email to