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.