Hi Jorge, I don't think JSR-375 is really overlapping with Keycloak. There we are discussing an API whether KC is a OOTB IAM server based on known federation protocols such as OpenID Connect and SAML. IMO, the real "overlap" is with PicketLink IdM and JEE Security. Depending on how that spec goes (right now it is pretty quiet), nothing stop us to provide something based on the JSR-375 in the future (maybe for things like user federation SPIs or an integrated and standard API for JEE apps secured by KC). Regards. Pedro Igor ----- Original Message ----- From: "Jorge Solórzano" <jorsol(a)gmail.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Wednesday, January 20, 2016 2:50:03 AM Subject: [keycloak-dev] Relation to JSR-375 Hi Keycloak developers, How is related Keycloak to the JSR 375 : Java TM EE Security API? I can see that Darran Lofthouse and Pedro Igor Silva are part of the Expert Group, and since this JSR overlap with many features of Keycloak (AFAIK) I wish to know if Keycloak will implement this API or if this API is unrelated to Keycloak. What are the plans about it? Regards, Jorge Solórzano http://www.jorsol.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Yeah, both projects were merged. But the merge was mainly around the federation bits of PicketLink, a.k.a PicketLink Federation, which provides support for SAML. You are right when you say that PL allows you to do more customization and that is what you get when using a security framework. However, KC also provides great flexibility and let's you customize almost everything: UI, authentication flows, identity management, identity brokering, all based on SPIs that you can implement to better fit your security requirements. KC makes security more easy as you don't need to know any API, how a specific security protocol works or even how to better manage your identities such as users, roles, groups and so forth. I think I understand your point, where you may not need a separated authentication server (plus infrastructure to support it) in order to support your security requirements. But we had to decide where we should put our efforts and what people are looking most. KC seems to be the perfect answer for that, an easy-to-use and standard-based IAM platform full of very common and useful security capabilities. Now, from a service provider point of view, when using KC you basically rely on the JEE security standards. It should be possible to still use PL JEE security with KC, where you may use KC tokens (OIDC or SAML) as a source of identity. Unfortunately, due to the PicketLink deprecation, we didn't get that further and we will not spend more time on that any time soon. So, I would recommend you to give KC a try and see how it can help you to address your security requirements. If you need something that is not provided OOTB, you can take a look at the SPIs or even ask for a specific feature/SPI. Best regards. Pedro Igor ----- Original Message ----- From: "Jorge Solórzano" <jorsol(a)gmail.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, January 20, 2016 12:24:54 PM Subject: Re: [keycloak-dev] Relation to JSR-375 Hi Pedro, Thanks for the clarification, but since PicketLink is "merged" with KC and it's discontinued, don't that means that KC overlap somehow? I'm just triying to understand what can be acomplish with PL and what with KC, I tend to think that PicketLink allows me to do more customization while KC follows a one-size-fits-all. Regards, Jorge Solórzano http://www.jorsol.com On Wed, Jan 20, 2016 at 6:11 AM, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: