[security-dev] Picketlink 2.8.0
Marek Posolda
mposolda at redhat.com
Wed Nov 25 05:29:05 EST 2015
On 24/11/15 11:50, Arthur Gregório wrote:
> I only use JPA/LDAP authentication, simple and not need to mess with
> XML and have only a single Jar in my classpath without relying on my
> aplication server or something.
With Keycloak, you also don't need to mess with any XML. The idea is,
that there is minimal code needed on application side. All the work like
authentication, identity management, LDAP integration, social
integration etc is done on Keycloak server. Your application just needs
to know how to talk to Keycloak server, so you need to add keycloak.json
file with some "adapter configuration", which points how your
application can talk to Keycloak server (it uses OpenID Connect or SAML2
protocols for communication with server) . The amount of dependencies on
application side is also quite minimal.
>
> In short, KC can be very good at it, but for those who already have
> something done and solid in the PL, it is impossible to migrate.
>
> Until someone says I can use the KC to do this [1] with the same
> effort that I have with the PL, I will continue thinking that the
> framework should receive attention again.
>
> [1]
> https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-authentication-form-with-jsf
The amount of effort on application side is even less than with
picketlink. The thing is that you need keycloak server. It can be
executed either in same JVM ( Wildfly/EAP instance) like your
application or on completely different server.
The best is to start with keycloak documentation and possibly
screencasts and try examples.
Marek
>
> *Arthur P. Gregório*
> /+55 45 9958-0302/
> @gregorioarthur
> www.arthurgregorio.eti.br <http://www.arthurgregorio.eti.br>
>
> 2015-11-24 5:46 GMT-02:00 Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>>:
>
> Keycloak now supports SAML SP implementation, which doesn't
> require KC server. It can talk to any other SAML Idp. The docs is
> here
> http://keycloak.github.io/docs/userguide/saml-client-adapter/html/index.html
> . For the future, we will mainly focus on improve/maintain the
> Keycloak SAML SP rather than Picketlink.
>
> Also there is no need to fork the Picketlink project to your own,
> you can still propose and send PR to Picketlink . This will allow
> that more people from the community can suffer from your work.
>
> Marek
>
>
>
> On 23/11/15 23:40, larry mccay wrote:
>> This is a disappointing situation.
>> PL should have been continued and then consumed by KC.
>> I will not be pulling in KC in its entirely in order to do SAML
>> SP implementations - we will need to move to something else.
>>
>> I suggest that a PL module be published from KC that has minimal
>> dependencies.
>> You can migrate the PL functionality to KC this way but not force
>> all of the new dependencies on consumers.
>>
>> On Mon, Nov 23, 2015 at 11:19 AM, Arthur Gregório
>> <arthurshakal at gmail.com <mailto:arthurshakal at gmail.com>> wrote:
>>
>> I see this post, and i know what KC do..
>>
>> What I mean is that I do not need all the things that KC
>> does, I want simple with the something like PL.
>>
>> I posted in a thread about it on the same topic "continuity
>> of PL" on the dev list of KC and the same answer was given.
>>
>> PL is such a cool framework, I refuse to believe that only I
>> use it or only I noticed this deep sleep that the project came...
>>
>> Finally, the fact is that PL is like Spring Security, a
>> swatter convenient and fast flies. KC is already like a
>> cannon, large and meaningless to the context of solving a
>> simple problem like killing a single mosquito.
>>
>> But if so, the business is to make a project fork and working
>> on my own version.
>>
>> at.,
>>
>> *Arthur P. Gregório*
>> /+55 45 9958-0302 <tel:%2B55%2045%209958-0302>/
>> @gregorioarthur
>> www.arthurgregorio.eti.br <http://www.arthurgregorio.eti.br>
>>
>> 2015-11-23 13:07 GMT-02:00 Bruno Oliveira
>> <bruno at abstractj.org <mailto:bruno at abstractj.org>>:
>>
>> Please take a look at
>> http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge/
>>
>>
>> I think this post answers your question.
>>
>> On Mon, Nov 23, 2015 at 1:05 PM Stephen Agneta
>> <sagneta at gmail.com <mailto:sagneta at gmail.com>> wrote:
>>
>> I'll share what I know with you in the hopes that it
>> will help somehow.
>>
>> Well KC (keycloak) is a super-set of the PL
>> (PicketLink) functionality thus in theory it ought to
>> work fine once it is ready and once some sort of
>> migration path is known. You may not wish to move to
>> KC due to the additional functionality which may be
>> off-putting for lite applications but KC will perform
>> everything PL did and more and will do so in VM
>> memory if you so choose.
>>
>> Essentially KC is a real federated authentication and
>> authorization service with identity management that
>> can run standalone or in-VM within a WildFly cluster.
>> Although a Java implementation it works with other
>> systems and languages out of process. It does
>> integrate with Spring which may interest you.
>>
>> The following link provides information for Wildfly 9
>> clustered installation:
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#overlay_install
>>
>> Thus you should be able to have your authorization
>> demands met _in VM_ as opposed to over-the-wire for
>> performance reasons if necessary.
>>
>> IMOP I think the KC project is the right move. They
>> are fixing the big issue which is the lack of an
>> opensource Federated Identity Management System. They
>> also fixed little things such as Composite Roles
>> which are missing from PL.
>>
>> I merely disliked the abrupt change-over. I also
>> can't move to keycloak until I have more of an idea
>> how the migration would work.
>> For example, how different is the default KC
>> relational schema from the default basic PL schema:
>>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e136
>>
>> It is also not clear if keycloak has a CDI demand
>> system ready like PicketLink. They only hint at it.
>> Also it runs in-cluster on Wildfly 9 and I am on 8.
>> Nothing huge but issues that will need to be addressed.
>>
>> Hope that helps.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 23, 2015 at 8:54 AM Arthur Gregório
>> <arthurshakal at gmail.com
>> <mailto:arthurshakal at gmail.com>> wrote:
>>
>> And KC does not have the same purpose as the PL.
>>
>> In short, I have no reason to migrate from one to
>> the other, I use PL or go back to Spring Security.
>>
>> But it seems that there has not been any
>> development in PL, at least in recent months, in
>> short, it seems that the project is dying and all
>> that were used for its own account.
>>
>> And with bugs like this
>> https://developer.jboss.org/thread/266387, it's
>> not cool to let the project stalled...
>>
>>
>> *Arthur P. Gregório*
>> /+55 45 9958-0302 <tel:%2B55%2045%209958-0302>/
>> @gregorioarthur
>> www.arthurgregorio.eti.br
>> <http://www.arthurgregorio.eti.br>
>>
>> 2015-11-23 11:47 GMT-02:00 Stephen Agneta
>> <sagneta at gmail.com <mailto:sagneta at gmail.com>>:
>>
>>
>> It certainly appears that everything has
>> moved to key-cloak but I am unsure that
>> keycloak is ready to take the burden of
>> current Picketlink implementations. Nor am I
>> sure how the migration process would occur.
>> The abruptness of the change is a bit
>> disconcerting. Having said that Picketlink is
>> working fine save for one defect that which I
>> requested that is on the git HEAD but not in
>> any particular release.
>>
>>
>>
>>
>> On Mon, Nov 23, 2015 at 8:43 AM Arthur
>> Gregório <arthurshakal at gmail.com
>> <mailto:arthurshakal at gmail.com>> wrote:
>>
>> Picketlink is dead?
>>
>> The last commit in the project repo was
>> in 9 july..
>>
>> Is there a schedule for the new version
>> or something like that?
>>
>> at.,
>>
>> *Arthur P. Gregório*
>> /+55 45 9958-0302
>> <tel:%2B55%2045%209958-0302>/
>> @gregorioarthur
>> www.arthurgregorio.eti.br
>> <http://www.arthurgregorio.eti.br>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> <mailto:security-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> <mailto:security-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>>
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> <mailto:security-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>>
>>
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org <mailto:security-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20151125/5cacfa2b/attachment-0001.html
More information about the security-dev
mailing list