Hi, Good news then! When it works better than I expected, it's always a good surprise!
Yes, the dependencies are now optional by default (to avoid pulling them all) and you must explicitly define what you need, wherever it's necessary (I remember of a dep directory). Thanks. Best regards, Jérôme On Thu, Sep 28, 2017 at 12:58 PM, Colm O hEigeartaigh <[email protected]> wrote: > I upgraded locally to use PAC4J 2.1.0 and J2E PAC4J 3.0.0 and it seems to > work, albeit I have a few queries about the changes that I'll raise in a > JIRA. > > One initial question: with the older PAC4J version, it included all of the > relevant components (SAML, OIDC, etc.) via the pac4j-config dependency. > This is not the case for 2.1.0 though. Is there any way of pulling all > these dependencies in, or do I have to list them individually in the pom? > > Larry, including the cert of the IdP in the Java cacerts works correctly. > But specifying it via "gateway.truststore.path" does not - looking at the > code I think this only applies to the SSL configuration of the server, > probably the metadata client code gets the truststore from the > "javax.net.ssl.trustStore" system property. > > Colm. > > On Wed, Sep 27, 2017 at 4:36 PM, Jérôme LELEU <[email protected]> wrote: > >> Hi, >> >> Yes, unfortunately, there are breaking changes between major versions: >> 1.8, 1.9, 2.0 and 3.0. So, for a drop/replace action, you should stick to >> the same streamline, which is certainly less interesting. >> >> That's why we need a real upgrade after the upgrade to Java 8 on Knox >> side. >> >> Thanks. >> Best regards, >> Jérôme >> >> >> On Wed, Sep 27, 2017 at 3:13 PM, larry mccay <[email protected]> >> wrote: >> >>> FYI - since we are officially dropping Java 7 support in 0.14.0/1.0.0 we >>> can upgrade our pac4j library. >>> If you are playing around with that then it may be interesting to drop >>> in the new version. >>> >>> I do suspect it will require some changes though. >>> >>> On Wed, Sep 27, 2017 at 8:11 AM, Colm O hEigeartaigh < >>> [email protected]> wrote: >>> >>>> Nevermind on this one, I can just use the http URL instead for the >>>> discovery doc and it works fine. >>>> >>>> Colm. >>>> >>>> On Wed, Sep 27, 2017 at 12:57 PM, Colm O hEigeartaigh < >>>> [email protected]> >>>> wrote: >>>> >>>> > Hi all, >>>> > >>>> > I'm playing around with using PAC4J to secure KnoxSSO, talking to an >>>> OIDC >>>> > IdP. I'm getting a TLS handshake error when trying to retrieve the >>>> OIDC >>>> > configuration as specified by the "oidc.discoveryUri" parameter: >>>> > >>>> > Caused by: org.pac4j.core.exception.TechnicalException: >>>> javax.net.ssl.SSLHandshakeException: >>>> > sun.security.validator.ValidatorException: PKIX path building failed: >>>> > sun.security.provider.certpath.SunCertPathBuilderException: unable to >>>> > find valid certification path to requested target >>>> > at org.pac4j.oidc.client.OidcClient.internalInit(OidcClient.jav >>>> a:297) >>>> > >>>> > How can I add the cert of the IdP to Knox/Pac4J so that the TLS >>>> handshake >>>> > works correctly? I tried adding it to gateway.jks but it doesn't >>>> work. Is >>>> > there a separate way to specify a TLS truststore? >>>> > >>>> > Colm. >>>> > >>>> > >>>> > -- >>>> > Colm O hEigeartaigh >>>> > >>>> > Talend Community Coder >>>> > http://coders.talend.com >>>> > >>>> >>>> >>>> >>>> -- >>>> Colm O hEigeartaigh >>>> >>>> Talend Community Coder >>>> http://coders.talend.com >>>> >>> >>> >> > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
