I feel ya... :-) My biggest concern at the moment, as others have posted about here as well, is the jwt is a url parameter when passed back to the client app. I would much rather it be a header or cookie or post param or anything really because my concern is until the jwt expiration time anyone who has access to the apache logs, syslogs, etc. of the cas server or the server hosting the client app, or has access to the network logs, or sniff the traffic in some way, could grab that url parameter and masquerade as that user to the client app.
I'm looking at the cas source code in hopes that I can make this an option(and make a pull request) but being a non-spring java developer my head is currently exploding with all the spring/lombok/etc. "magic" I am having to learn. Not to mention the large amount of highly modularized code. It's looks well written and well commented, it's just a lot to take in. Importing it into eclipse created about a hundred or so source folders I am currently perusing. Argh. On Wednesday, April 18, 2018 at 7:21:43 AM UTC-5, Karl Banke wrote: > > Hello there, > > I am using CAS 5.2 and have spent a long time (which translates to a lot > of money) on getting JWT Service Tickets to work. > > The CAS documentation states here > > > https://apereo.github.io/cas/5.2.x/installation/Configure-ServiceTicket-JWT.html > > that this should be configured using the > > jwtAsServiceTicket Property > > It also states here > > https://apereo.github.io/cas/5.2.x/installation/Configuration-Properties.html#jwt-tickets > > that the signing key is a JWK > > My findings so far: > > JWT service tickets do not work at all in CAS 5.2.0. They work in 5.2.4. > > But there are some weired "limitations" that I only figured out running CAS > inside my debugger. > > (a) The property name is wrong. The property that actually leads to anything > happening is jwtAsResponse, as others have pointed out in this community. > > But even then....I would like to sign my JWTs with a public RSA key in order > to allow Single Page Web Applications to validate the keys. > > (b) When trying to read the private key, the code does never look for a JWK, > but - in PrivateKeyFactoryBean - tries to parse a PEM file. > (c) Even if one is lucky enough to eventually have a RSA key inside the > privateKey by supplying a PEM file, you run in trouble because. > -- taataaa -- > the AbstractCipherExecutor calls a hardcoded method called > EncodingUtils.signJwsHMACSha512 > (d) If you chose not to encrypt the JWT payload, you may rest assured that > you get another problem, because someone chose to Base64 encode the payload > twice rather than once. > > > I have also considered using the OpenID Connect flow instead of the JWT > Service tokens, but since this is a much more complicated interface my > expectation > is that it's implementation is even more broken and its documentation more > inaccurate. > > Sorry for the rant, but I am really about to lose patience with CAS that > used to be a very usable, well documented and extensible tool. > > > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/fd5502dd-f0bc-46b4-bedb-942d162ab5ff%40apereo.org.
