[aerogear-dev] Aerogear Security (Picketlink)? enhancements

[Karel Piwko]

On Tue, 05 Nov 2013 11:19:19 -0200
Bruno Oliveira <bruno at abstractj.org> wrote:

> Answers inline.
> 
> Karel Piwko wrote:
> > Hey,
> >
> > I've integrated Aerogear Security with PicketLink installed as JBoss
> > submodule. I find following challenges complicating the setup/reducing
> > feature set and I think they should be addressed:
> >
> > 1/ Aerogear Security Submodule - if you install PL as module and add it as
> > dependency into jboss-deployment-structure.xml, you need to manually exclude
> > plenty of PL deps from pom.xml. I think that easiest way how make setup more
> > convenient would be to create Aerogear Security PL submodule on top
> > of PL submodule and then easily mark aerogear-security-pickelink as
> > 'provided' in pom.xml
> Hi Karel, on AeroGear we do not enforce the usage of AG Security, so if
> you want use only PicketLink it's up to you. Either way suggestions to
> improve AG Sec are more than welcome, if you are planning to open a
> Jira, please make sure to add the steps to reproduce it, please.

Definitely, I'll do that, I think it would be a nice feature request -
usability improvement.

> > 2/ AuthenticationManager/CredentialsMatcher is limited to (T user,
> > String password). However, PL allows more ways of authentication [1] and
> > here we are simply reducing feature set. I think there should be login(T
> > user, C credentials) operation as well. There could also be just login(T
> > user) and impl will be responsible to inject/produce/select correct
> > CredentialsHandler.
> As I mentioned on AG Sec we tried to make developer's life simple, we
> are not reducing any feature. If advanced developers want to make use of
> the features on PicketLink, they should stick with the PL API instead,
> we don't want to create a wrapper on top of PicketLink. The idea is: if
> you want to go simple, go with AGSec and if you want advance features,
> make use of PL API.

I fully understand the plan of not copying PL API. My concern was AGSEC API not
being flexible enough. Let me give you scenario:

1/ User writes app and secures methods using @Secure annotation
2/ Later on, as app evolves, there is a need to use LDAP binding without
password or auth via certificate/fingerprint/whatever
3/ Doh, app needs to be rewritten

The issue here is that String based password is not easily extensible. Having
richer API does not impose any implementation. It can be left to user to write
the integration layer.

> 
> Any scenario where that method signature should be applied? Please
> provide the scenario or the sources where AG Sec is blocking you.
> > Let me know your opinions and I can create JIRAs based on outcome.
> >
> > Thanks,
> >
> > Karel
>