6:08 a.m.
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
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.
Let me know your opinions and I can create JIRAs based on outcome.
Thanks,
Karel
[1] http://docs.jboss.org/picketlink/2/latest/reference/html_single/#d5e776
7:19 a.m.
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.
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.
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
--
abstractj
9:40 a.m.
On Tue, 05 Nov 2013 11:19:19 -0200
Bruno Oliveira <bruno(a)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
11:05 a.m.
Ahoy!
On November 7, 2013 at 1:40:32 PM, Karel Piwko (kpiwko(a)redhat.com) wrote:
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
I totally understand and open for suggestions. So feel free to add the corner cases to
AGSEC.
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.
+1 makes sense.
--
abstractj
4066
days inactive
4068
days old
3 comments
2 participants
participants (2)
-
Bruno Oliveira -
Karel Piwko