0 Replies Latest reply on Jun 25, 2015 1:02 PM by Benjamin Arnold

    picketlink-bindings for wildfly NPE getting STSClientPool

    Benjamin Arnold Newbie

      It seams like the WSTrustClient tooling was updated for the Tomcat bindings but not WildFly https://bugzilla.redhat.com/show_bug.cgi?id=1117803.


      Following PicketLink Security Token Service article gives me the same NPE as in the above mentioned bug.  The changeset for the picketlink-bindings, only effected the tomcat bindings.  Moreover, the wildfly binding code (SAMLEndpoint/SAMLOAuthEndpoint) seems to favor a RESTful solution over the previous SOAP clients.


      Our end goal is to tie a STS token-generating service in a central security application to an (extended) LdapLoginModule for authentication.  This would enable a token-based SSO among our applications with distributed login screens rather than the central login favored by IdP/SP SSO.


      Does this mean that in WildFly we should be following a similar pattern as in SAMLEndpointTestCase?

      The documentation WS-Trust and STS - WildFly 8 - Project Documentation Editor by contrast focuses on extending CXF WS-Security which seems at odds with the picketlink-bindings source code.

      Any advise on which would be the correct approach is appreciated, especially bearing in mind the significant security rewrite for WildFly 10 and picketlink-keycloak merge.