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?