We will still continue to have a SAML SP adapter, but the APIs/SPIs will
change. We will have an SPFilter as well as tomcat, jetty, eap 6.x, and
Wildfly integrated adapters for SAML.
On 3/20/2015 4:50 PM, jboss.atomicknight(a)xoxy.net wrote:
Hi there,
I'm writing with regard to the announcement about PicketLink merging
into Keycloak, particularly as it pertains to the SAML capabilities and
APIs currently offered by PicketLink today.
From what I understand, the focus of Keycloak has historically been to
provide a standalone application/appliance that runs "out of process"
relative to an application utilizing those capabilities. In contrast,
PicketLink has been focused on lower-level APIs that are intended to be
integrated "in process" relative to the application. Is this
understanding correct? If so, will the combined project continue to
support both approaches?
More specifically, my company has developed an application that relies
on PicketLink's SAML APIs to provide SAML support as part of a larger
security subsystem. This uses the SPFilter class and the associated
SAML2Handler classes to handle SAML messages, but adapts the
inputs/outputs to plug into the existing security infrastructure (not
built using PicketLink). Going forward, will these parts of the merged
codebase still be supported as first class Java APIs? Or will they be
replaced by web service APIs or other equivalent endpoints?
Thanks in advance for your help.
-Abraham
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com