IdentityManager interface
by Jason Porter
Hey all,
I'm going through the API again as I've seen some changes since I last went
through it. I may be the only one in this boat, but I feel like this
interface is starting to become too crowded. Should some of the methods be
moved over to their respective objects (Identity, User, Role, Group, etc)?
Should we split things off into a different interface? I'm also becoming
concerned with the password and certificate methods on there.
It seems to me these are essentially authentication challenges. Eventually
I'm sure we'll add more like OAuth or OpenId, two-factor auth, etc. Will
each of these be their own methods? Could it be a configuration option to
build up a chain of authentication challenge providers? I had initially
thought of a challenge object which would allow input and provide a simple
response: pass, fail, move to next challenge. Maybe that's too broad or a
bad idea, I don't really know, just throwing out ideas.
Just looking to make this easy to use and make sure it makes sense to users
(who I think would be coming from a Java EE background).
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
11 years, 7 months
Review of IDM API
by Jason Porter
== Picketlink IDM API Review ==
=== General ===
* We should probably implement a good hashcode and equals for our simple
implementations in the API.
=== AbstractIdentityType / IdentityType ===
* getCreationDate should return a copy / clone of the date
* setAttribute might be easier to use if it were vararg
* getAttribute Would returning the first value be expected? Maybe it should
be renamed to getFirstAttributeValue?
* getAttributeValues should also return a clone of the array
=== Range ===
* The private no args constructor is redundant because there's already a
ctor with args
=== Queries ===
* Maybe it's just me, but these are all a type of query and have some
things in common. It makes sense to me, and we could make things DRY by
pulling those things out into a common interface (maybe also use generics)
and cut down on the implementation a bit.
=== IdentityStore ====
* Having two executeQuery methods, one without the Range would be a little
more user friendly when you don't want to use a range or don't need one.
* I see no point in having all the get, set, remove methods on
IdentityStore. It blurs the line of what you would expect it to do based on
its name and doesn't separate concerns. I would figure it would have
retrieve and store methods for IdentityType, Group, Role and User then
you'd modify those objects as needed and store them when you're done just
like with JPA entities.
=== SecurityConfigurationException / SecurityException ===
* We should remove the ctors that don't set a message. An exception w/o a
message for the user is worthless.
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
11 years, 7 months
Checkpointed/Snapshot/Timed Releases on Sept 14
by Anil Saldhana
Hi all,
I propose that we do a checkpoint of the security projects on sept
14th to enable demos at JavaOne.
Basically, we will just do a checkpoint snapshot releases of projects in
development.
Thoughts?
Regards,
Anil
11 years, 7 months
Aerogear wants a timed release of PL CDI project
by Anil Saldhana
Hey Shane,
I was chatting with Bruno and the Aerogear guys. They are interested
in seeing a timed release of PL CDI project, which I presume you are
currently working. The timed release can be something like 1.0.0.2012sep4
They cannot move forward without the PL CDI api. They will need to redo
their previous work due to the security api being refactored out of the
Deltaspike project into PL CDI.
Cheers.
11 years, 7 months
