<div dir="ltr"><div>Then KC will not have a model in the style of the PL?</div><div><br></div><div>This means that those who used the PL hoping that everything in it was in KC turned out to have a framework discontinued and with no more updates?</div><div><br></div><div>Or the PL as it exists today will continue to be developed and there will be a plus integration with KC?</div><div><br></div><div>I am very confused by the merge of the projects, it appears that the security of my system already died before were born.</div><div><br></div><div>at.,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><b>Arthur P. Gregório</b><br><i>+55 45 9958-0302</i><br>@gregorioarthur<br><a href="http://www.arthurgregorio.eti.br" target="_blank">www.arthurgregorio.eti.br</a><br></div></div>
<br><div class="gmail_quote">2015-10-19 10:24 GMT-02:00 Pedro Igor Silva <span dir="ltr"><<a href="mailto:psilva@redhat.com" target="_blank">psilva@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Crhisthian,<br>
<br>
As Bill said, we are working on an Authz Server for Keycloak in order to provide fine-grained permissions. It is still a working in progress, although we already have a baseline for a first release which will happen very soon.<br>
<br>
From a migration perspective, while PL provides a rich Permission Java API, Keycloak will provide a distributable authorization server based on a RESTful API to manage resources, policies, evaluate policies, obtain entitlements and plus other goodies. In other words, Keycloak will become a PAP (Policy Administration Point), a PDP (Policy Decision Point) and a Entitlements Server. Everything based on OpenID Connect (and of course, oAuth2).<br>
<br>
As you know, Keycloak is a feature rich, OOTB and easy to use security as a service solution. We are considering these same premises for the authz server, so you can protect web apps, RESTful APIs or any other resources very easily. For instance, you'll be able to write policies using JBoss Drools, EL and easily extend your existing oAuth2 clients in order ask for permissions or enforce them (in case your client acts as a resource server).<br>
<br>
I'm afraid there will be no "migragration path" between PL and KC, at this sense. But we can work together to make this migration easier. For instance, we are going to provide a Protection API which can be used to manage resources and policies remotely.<br>
<br>
Regards.<br>
<span class="HOEnZb"><font color="#888888">Pedro Igor<br>
</font></span><span class="im HOEnZb"><br>
----- Original Message -----<br>
From: "Cristhian Camilo Lopez" <<a href="mailto:calovi86@gmail.com">calovi86@gmail.com</a>><br>
To: <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
Sent: Sunday, October 18, 2015 3:16:30 PM<br>
Subject: Re: [keycloak-dev] Authz Model Implementation<br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">Hi Pedro,<br>
<br>
I'm migrating from Picketlink, but I haven't found the way to use fine-grained permissions, Could u give me some advice on this ?<br>
<br>
Thanks,<br>
<br>
Cristhian.<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>