[security-dev] IdentityManager interface

[Jason Porter]

On Wed, Sep 26, 2012 at 2:23 PM, Shane Bryzak <sbryzak at redhat.com> wrote:

>  On 27/09/12 05:24, Jason Porter wrote:
>
> 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 does look like some new methods have crept in.  Which methods would you
> suggest moving over?  The identity model objects are designed to be
> lightweight and non-relational.
>

 For sure the ones about password and certificate if that's what is going
to happen as you mentioned below. setEnabled and setExpirationDate. As you
say, if the identity model objects are not supposed to be relational, those
just seems to naturally fit on an identity object.

I still wonder if a get(Class, Object identifier) (i.e. get(Group.class,
id) or get(Role.class, name) and similar) is more familiar to users. The
getGroup and getRole though are nice to know what you're expecting. Maybe
it's just a preference thing there. Same thing with createQuery(Class).

Also IdentityStore and IdentityManager are very similar, seems to me like
we could pull some things out and create some common interface or something.

>  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.
>
>
> I agree with the concern over certificate methods being there, we
> originally just had password methods to cover the 90% use case.  If we're
> going to start managing other forms of credentials, we should look at
> abstracting out all credential management.
>
>
>  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
>
>
> _______________________________________________
> security-dev mailing listsecurity-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/security-dev
>
>
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20120926/33cc3bcb/attachment.html