2:24 p.m.
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
3:23 p.m.
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.
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 <http://keyserver.net>;,
pgp.mit.edu <http://pgp.mit.edu>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
4:12 p.m.
On Wed, Sep 26, 2012 at 2:23 PM, Shane Bryzak <sbryzak(a)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@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
9:46 a.m.
On 09/26/2012 02:24 PM, 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.
For each user/application, there can be multiple
things that need to be
secured:
- passwords
- oauth consumer secret
- certificates
As you later say, we probably need another class to manage these, rather
than being in IdentityManager and IdentityStore.
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 have already used PL IDM in my oauth project. The
biggest question I
had was how do we represent applications that need to have a consumer
key and consumer secret along with app name, app description, app icon
and app redirect URL. Right now, I just modeled the application as an User.
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).
Users will deal with
IdentityManager interface alone. IdentityStore
interface is used by implementers of data store bridges - JPA, LDAP,
file etc etc.
3:22 p.m.
Hi All,
As Anil suggested, I've created a gist with some side notes regarding the
PicketLink IDM API.
There is also a "Additional Requirements" section where you can put some
specific requirement or use case.
You can check it here: https://gist.github.com/3801805.
Regards.
Pedro Igor
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Thursday, September 27, 2012 11:46:09 AM
Subject: Re: [security-dev] IdentityManager interface
On 09/26/2012 02:24 PM, 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.
For each user/application, there can be multiple
things that need to be
secured:
- passwords
- oauth consumer secret
- certificates
As you later say, we probably need another class to manage these, rather
than being in IdentityManager and IdentityStore.
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 have already used PL IDM in my oauth project. The
biggest question I
had was how do we represent applications that need to have a consumer
key and consumer secret along with app name, app description, app icon
and app redirect URL. Right now, I just modeled the application as an User.
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).
Users will deal with
IdentityManager interface alone. IdentityStore
interface is used by implementers of data store bridges - JPA, LDAP,
file etc etc.
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
4437
days inactive
4439
days old
4 comments
4 participants
participants (4)
-
Anil Saldhana -
Jason Porter -
Pedro Igor Silva -
Shane Bryzak