Displaying #apache-syncope/2017-07-28.log:

Fri Jul 28 05:56:01 2017  fmartelli:Joined the channel
Fri Jul 28 06:29:11 2017  ilgrosso:Joined the channel
Fri Jul 28 06:57:28 2017  andreapatricelli:Joined the channel
Fri Jul 28 07:03:35 2017  svizzero81:Joined the channel
Fri Jul 28 08:42:11 2017  coheigea:Joined the channel
Fri Jul 28 08:56:40 2017  ilgrosso:coheigea: ping
Fri Jul 28 08:56:46 2017  coheigea:ilgrosso: pong
Fri Jul 28 08:57:13 2017  ilgrosso:I've just attached a patch to https://issues.apache.org/jira/browse/SYNCOPE-1175 - this is the kind of solution I was thinking of, for that problem and related
Fri Jul 28 08:57:21 2017  ilgrosso:have you had the chance to review it?
Fri Jul 28 08:57:35 2017  coheigea:ilgrosso: Not yet, I'll look at it shortly
Fri Jul 28 08:57:42 2017  ilgrosso:coheigea: thx
Fri Jul 28 09:32:09 2017  fmartelli:Joined the channel
Fri Jul 28 11:12:40 2017  ilgrosso:coheigea: any feedback?
Fri Jul 28 11:14:22 2017  coheigea:ilgrosso: Looks good to me
Fri Jul 28 11:20:13 2017  ilgrosso:coheigea: great, I'll push that commit then, thx
Fri Jul 28 11:37:58 2017  coheigea:ilgrosso: ping
Fri Jul 28 11:38:05 2017  ilgrosso:coheigea: pong
Fri Jul 28 11:40:00 2017  jbonofre:Joined the channel
Fri Jul 28 11:40:15 2017  coheigea:ilgrosso: I've come across a bug with the way we treat expiry/issuedAt etc. times in Syncope with JWT tokens. The value is interpreted in milliseconds. However, that is not correct according to the spec "A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds."
Fri Jul 28 11:40:33 2017  coheigea:ilgrosso: Any objection if I change it to use seconds instead?
Fri Jul 28 11:40:49 2017  ilgrosso:coheigea: not at all, thx for noticing :-)
Fri Jul 28 11:40:55 2017  coheigea:ok cool
Fri Jul 28 12:59:07 2017  fmartelli:Joined the channel
Fri Jul 28 14:47:55 2017  andreapatricelli:Joined the channel
Fri Jul 28 15:02:25 2017  coheigea:ilgrosso: ping
Fri Jul 28 15:02:31 2017  ilgrosso:coheigea: pong
Fri Jul 28 15:04:08 2017  coheigea:ilgrosso: We currently get a JWTSSOProvider implementation by querying "getIssuer" in AuthDataAccessor.getJWTSSOProvider.
Fri Jul 28 15:04:37 2017  coheigea:I'm wondering if we should make this a bit more flexible, to allow multiple implementations of the same issuer but to handle different signature algorithms?
Fri Jul 28 15:05:08 2017  coheigea:The JWTSSOProvider inherits the method getAlgorithm from CXF, so we could just check this against the signature algorithm of the token as well.
Fri Jul 28 15:07:13 2017  ilgrosso:is there a real-world use case for this?
Fri Jul 28 15:07:43 2017  ilgrosso:I don't see it as a real limitation: one can always create two issuers
Fri Jul 28 15:08:46 2017  coheigea:yeah maybe so. I was just thinking out loud :-)
Fri Jul 28 15:09:57 2017  ilgrosso:well, keep thinking is important indeed ;-)
Fri Jul 28 15:12:03 2017  coheigea:hehe
Fri Jul 28 15:57:09 2017  fmartelli:Joined the channel
Fri Jul 28 18:11:44 2017  coheigea:Joined the channel
Fri Jul 28 20:38:31 2017  coheigea:Left the channel

Comments