#picketlink channel on irc
by Shane Bryzak
Hey guys,
Just a reminder that many of us hang out in the #picketlink channel on
IRC, and (lately at least) many development discussions have been going
on there especially in relation to the identity management work we've
been doing. Of course, important development decisions will always be
posted to this mailing list however I encourage anyone that's interested
to join us in IRC if you would like to contribute or simply to stay in
touch with what's going on with the PicketLink project.
Shane
13 years, 9 months
IDM:: API Change question - feedback requested
by Anil Saldhana
Hi all,
Shane, Pedro and I have been discussing the following use case and
agree on method name change. Shane suggested the list due to it being an
API change.
The developer can ask the Identity Manager to create an instance of
User/Role/Group (IdentityType). This use case is pretty clear.
Now if the developer wants to create his own instances of U/R/G as:
User user = new SimpleUser("userA");
Now he needs to persist this to the store.
The current API call would be:
User storeUser = identityManager.createUser(user)
We feel this is not as intuitive as:
User storeUser = identityManager.persist(user)
Objections to this API change?
Regards,
Anil
13 years, 10 months
[PicketLink IDM] - Loading LDAP Attributes
by Pedro Igor Silva
Hi All,
Anil, Shane and I have been discussing if is worth to add a configuration to the LDAP store that allows to specify which attributes should be loaded when retrieving users, roles and groups from the LDAP server.
The point is that LDAP entries can have a lot of attributes and if we pre-define which attributes should be loaded (and managed by the IDM) we may have a better performance when retrieving the entries from the server.
This feature is related with lazy loaded attributes.
Regards.
Pedro Igor
13 years, 10 months
IDM Design Session : IRC Chat Transcript
by Anil Saldhana
(04:45:19 PM) psilva [~pedroigor(a)187.36.71.92] entered the room.
(04:45:37 PM) psilva: sbryzak: r u around ?
(05:37:08 PM) sbryzak: psilva: yes
(05:37:22 PM) sbryzak: sorry, xchat doesn't give me very good notifications
(05:45:40 PM) psilva: sbryzak: nice ... did you see my latest changes to
the tests ?
(05:46:06 PM) sbryzak: psilva: i haven't looked at them in detail yet..
the tests are failing in my build, is that correct?
(05:46:42 PM) psilva: sbryzak: not sure about the other tests. The ones
I'm working with are fine ... Going to work with the others later ...
(05:47:25 PM) sbryzak: psilva: sounds good, one important thing that
needs doing is to separate the configuration from the ldap and file
based identity stores
(05:47:27 PM) psilva: sbryzak: anyway, I've added two more test cases:
for roles and groups management. The test cases are now store-agnostic ...
(05:47:44 PM) asaldhan: sbryzak: psilva:
https://docs.jboss.org/author/display/PLINK/PicketLink+IDM
(05:47:59 PM) asaldhan: psilva: we are missing updateRole and
updateGroup methods for testing
(05:48:00 PM) sbryzak: psilva: great
(05:48:26 PM) psilva: sbryzak: yeah ... i put those on my side notes ...
just going to ask sbryzak about that :)
(05:49:57 PM) psilva: sbryzak: back to the store config ... i started to
do that for the LDAP store. But I found some gaps in the test cases. I'm
adding some test methods to enable and expiry users, roles and groups.
(05:50:39 PM) sbryzak: psilva: no problem
(05:50:53 PM) sbryzak: psilva: i'm concentrating on getting the
implementation complete for JPAIdentityStore
(05:51:02 PM) psilva: sbryzak: nice
(05:51:09 PM) sbryzak: and addressing any api gaps we have in other areas
(05:51:13 PM) qmx|away is now known as qmx
(05:51:32 PM) sbryzak: i'm currently working on partition management
(realms and tiers) as that part of the api is a little sparse right now
(05:53:20 PM) psilva: sbryzak: btw, i'm implementing the setEnable and
setExpirationDate methods (identitymanager) ...
(05:53:46 PM) sbryzak: psilva: no problem
(05:54:08 PM) sbryzak: i'm going to introduce a super-interface for
IdentityStoreConfiguration and PartitionStoreConfiguration, simply
called StoreConfiguration
(05:54:29 PM) sbryzak: so IdentityConfiguration will accept either type
of store configuration
(05:54:47 PM) psilva: sbryzak: nice
(05:54:52 PM) psilva: sbryzak: another important thing ... like Anil
said .. maybe we need a updateRole and updateGroup methods in the
IdentityManager interface. As we have for updateUser. What you say ?
(05:55:20 PM) sbryzak: hmm, i'm not sure
(05:55:25 PM) sbryzak: what's the use case for updateRole?
(05:55:29 PM) psilva: sbryzak: or a updateIdentityType ... that expects
a IdentityType ..
(05:55:30 PM) sbryzak: i think updateGroup will be problematic
(05:55:54 PM) psilva: sbryzak: actually we need to update roles and
groups when we add/remove/update attributes, for example ...
(05:56:30 PM) sbryzak: well no, we can use the
setAttribute()/removeAttribute() methods for that
(05:56:42 PM) psilva: sbryzak: from the IdentityManager ?
(05:56:44 PM) sbryzak: yes
(05:56:57 PM) sbryzak: managing attribute values is no problem
(05:57:20 PM) sbryzak: the issues start when you allow groups to be updated
(05:57:23 PM) psilva: sbryzak: i agree, but the user may want to not use
the identitymanager instance, but the role or group instance directly ...
(05:58:22 PM) psilva: sbryzak: or you want to remove the set/remove/
attributes from roles and groups and leave them only on the user ?
(05:58:40 PM) psilva: sbryzak: sorry methods .. not attributes ..
(05:59:00 PM) sbryzak: well, it's ok if they only want to update the
expiry date, enabled property or attribute values
(05:59:21 PM) sbryzak: but we should forbid updates to the group name or
parent group
(05:59:32 PM) sbryzak: i think it can have detrimental side effects
(05:59:52 PM) psilva: sbryzak: yeah, that is not possible until I know
... I'm talking only about attributes, custom attributes ...
(06:00:17 PM) sbryzak: ok, so how about we allow it, but with a caveat
that you cannot update the name or parent
(06:00:50 PM) psilva: sbryzak: for me is more than better :) otherwise,
like you say, we may have serious problems ... :)
(06:01:01 PM) psilva: sbryzak: like you said ..
(06:01:20 PM) sbryzak: same goes for role, we can allow an update for
everything except for the role name
(06:01:58 PM) psilva: sbryzak: fine .. so I'm going to add the
updateRole and updateGroup methods. that is one important missing part
for the current tests.
(06:02:11 PM) sbryzak: psilva: no problem
(06:22:28 PM) misty left the room (quit: Quit: Linkinus -
http://linkinus.com).
(06:24:28 PM) asaldhan: psilva: sbryzak: updatexxx maybe as simple as
(delete + create). The IDM developers may expect consistent api for all
identity type
(06:25:06 PM) psilva: asaldhan: ok
(06:25:55 PM) sbryzak: the trouble with delete is that it will delete
all relationships
(06:26:24 PM) asaldhan: psilva: sbryzak: api looks decent for
user/role/group
(06:26:39 PM) psilva: asaldhan: yeah :)
(06:26:53 PM) psilva: intuitive ...
(06:27:01 PM) asaldhan: sbryzak: from developer perspective, he may want
to update user/role/group. How it gets done is left to our impl
(06:27:38 PM) sbryzak: yes, i'm just saying that our impl can't do a
delete + create, at least in the JPA implementation as that would remove
all memberships for that role/group
(06:27:56 PM) asaldhan: psilva: was thinking about this. //create user
User user = new SimpleUser(); Then we say create user via
IdentityManager in the store. im.createUser(user)
(06:28:03 PM) asaldhan: psilva: is that intuitive.
(06:28:19 PM) asaldhan: psilva: or something like im.attach(user)
(06:28:30 PM) sbryzak: asaldhan: the first example is correct
(06:28:41 PM) sbryzak: create the User instance, then call
im.createUser(user) to persist it
(06:29:05 PM) asaldhan: sbryzak: I know. But I was thinking from
developer perspective.
(06:29:31 PM) sbryzak: i think it's intuitive from a dev perspective
(06:29:41 PM) psilva: asaldhan: i think the first is better from a dev
perspective ...
(06:29:45 PM) asaldhan: sbryzak: would he be better off by saying
im.persist(user)
(06:30:13 PM) asaldhan: sbryzak: he has done all the method calls on the
User instance and then asks im to persist it.
(06:30:17 PM) sbryzak: hmm
(06:30:31 PM) asaldhan: sbryzak: it is the wording createUser that is
putting me off a bit
(06:30:35 PM) psilva: asaldhan: or even create/persist(IdentityType) ...
(06:31:00 PM) psilva: asaldhan: sbryzak: and make the IM interface more
simple ...
(06:31:01 PM) asaldhan: psilva: if u did im.createUser("anil") I
know it gets persisted
(06:31:11 PM) sbryzak: if we were to do that i'd just make it
persist(IdentityType)
(06:31:26 PM) sbryzak: and update(IdentityType) and remove(IdentityType)
(06:31:32 PM) asaldhan: psilva: but since I created a SimpleUser
instance myself. maybe I just have persist(user)
(06:31:51 PM) sbryzak: asaldhan: maybe put it to the security-dev list
(06:32:02 PM) asaldhan: sbryzak: yeah. best is to replace
createUser(User) with persist(identityType)
(06:32:04 PM) sbryzak: see what people think is better
(06:32:11 PM) psilva: asaldhan: i have no problem with that ... maybe we
can use the persist for insert and update. And remove the update methods ...
(06:32:13 PM) asaldhan: 3 people not enough?
(06:32:43 PM) sbryzak: well, i think i'm ok with changing it, but i'd
like to give everyone a chance to provide input
(06:32:47 PM) sbryzak: it's a pretty major change to the api :)
(06:33:31 PM) asaldhan: sbryzak: makes sense. what we are proposing
is how the IM attachment of developer created instances happen. I
feel createxxx is not the right wording
(06:33:39 PM) sbryzak: JPA provides persist(), remove() and merge() methods
(06:33:49 PM) asaldhan: sbryzak: right.
(06:33:53 PM) sbryzak: what we are suggesting is analogous to that
(06:33:57 PM) psilva: sbryzak: what about having only the persist for
insert and update ? And remove the update methods ? Internally the store
can check if the instance is already stored or no.
(06:34:05 PM) psilva: asaldhan: ^
(06:34:20 PM) asaldhan: psilva: big change.
(06:34:26 PM) psilva: :)
(06:34:28 PM) asaldhan: psilva: not suitable
(06:34:46 PM) sbryzak: i think i'd rather have separate operations for
persist and update
(06:34:54 PM) psilva: ok
(06:35:07 PM) sbryzak: that way you don't accidentally overwrite an
existing user details unless you really mean to
(06:35:29 PM) psilva: yeah .. and the impl is more simple. Avoid some if
statements ...
(06:35:55 PM) sbryzak: asaldhan: do you want to write up these ideas in
a post for security-dev ?
(06:37:09 PM) asaldhan: sbryzak: already typed the email. sending in 2-3 m
(06:37:17 PM) asaldhan: sbryzak: in the replies, u can add more info
(06:37:48 PM) sbryzak: asaldhan: sure thing
(06:40:23 PM) asaldhan: sent
(07:24:40 PM) sbryzak: wow it took about 40 minutes for the email to
appear in my security-dev folder
(07:26:21 PM) psilva: sbryzak: just pushed the
JPAIdentityStoreTestSuite.
https://github.com/picketlink/picketlink/commit/e1e3220f5c510ca5cca20e931...
(07:26:22 PM) jbossbot: git [picketlink] e1e3220.. pedroigor Added
JPAIdentityStoreTestSuite for testing the IdentityManager using a
JPA-based store.
(07:26:48 PM) psilva: sbryzak: you can use it to run the test cases for
users, roles and groups.
(07:33:12 PM) sbryzak: psilva: thanks
(07:39:10 PM) psilva: sbryzak: what is the use case/requirement for
set/remove methods for attributes on the IdentityManager interface ?
(07:40:00 PM) sbryzak: psilva: the idea was that some attribute values
could be lazy loaded
(07:40:40 PM) misty [misty@redhat/jboss/misty] entered the room.
(07:40:43 PM) sbryzak: also for convenience of attribute management
(07:41:23 PM) psilva: sbryzak: so maybe we should have only the get
method .... and leave the set/remove only on the identitytype instance.
wdyt ?
(07:41:42 PM) psilva: sbryzak: just trying to make the IM more simple ...
(07:42:28 PM) sbryzak: hmm, let me think about it for a while
(08:54:07 PM) psilva: sbryzak: need to go now ... cya tomorrow ... have
a nice day ..
(08:54:14 PM) psilva left the room (quit: Quit: Leaving.).
(09:03:54 PM) qmx is now known as qmx|away
(11:42:58 PM) misty left the room (quit: Quit: Linkinus -
http://linkinus.com).
(12:01:49 AM) pskopek [pskopek@nat/redhat/x-wdjvylqwgtgvjfgp] entered
the room.
---
(08:06:51 AM) The topic for #picketlink is: Only discussion on
PicketLink (http://jboss.org/picketlink)
(08:21:57 AM) qmx is now known as qmx|brb
(08:43:29 AM) qmx|brb is now known as qmx
(08:48:06 AM) psilva|bbl is now known as psilva1
(08:48:52 AM) balunasj [~balunasj@redhat/jboss/balunasj] entered the room.
(09:04:41 AM) balunasj is now known as balunasj|mtg
(09:12:54 AM) jcacek left the room (quit: Quit: Ex-Chat).
(09:34:16 AM) qmx is now known as qmx|lunch
(09:43:00 AM) pskopek left the room (quit: Quit: Leaving).
(10:29:56 AM) You are now known as asaldhan_bbl
(10:52:29 AM) qmx|lunch is now known as qmx
(10:57:52 AM) ssadeghi left the room (quit: Ping timeout: 250 seconds).
(11:12:44 AM) balunasj|mtg is now known as balunasj|lunch
(12:58:20 PM) balunasj|lunch is now known as balunasj|mtg
(02:08:05 PM) jcacek [~jcacek(a)212-96-187-122.cust.selfnet.cz] entered
the room.
(03:22:46 PM) You are now known as asaldhan
(03:35:41 PM) qmx is now known as qmx|away
(04:30:38 PM) jcacek left the room (quit: Quit: Ex-Chat).
(04:37:00 PM) psilva1: sbryzak: r u around ?
(04:37:13 PM) sbryzak: psilva1: yes
(04:38:03 PM) psilva1: sbryzak: hi ... it seems we do not have a
setEnable method on the IdentityStore. Wondering if we should create one
or do something different ...
(04:38:47 PM) sbryzak: i think we can just add one
(04:38:49 PM) sbryzak: would you like to do it
(04:38:50 PM) sbryzak: ?
(04:38:59 PM) psilva1: sbryzak: the different thing is remove the
setEnable from the IM interface and move it to the IdentityType
interface. So we can enable/disable U/R/G directly ...
(04:39:20 PM) psilva1: sbryzak: yeah, i can do it .. just want to see
what you think about ^, first ...
(04:39:54 PM) psilva1: sbryzak: the same issue goes to the
setExpirationDate ...
(04:40:39 PM) sbryzak: hmm, so you're thinking of removing both
setEnabled() and setExpirationDate() and just use the update() method
instead?
(04:40:50 PM) psilva1: sbryzak: yeah ...
(04:41:44 PM) sbryzak: i guess that makes sense, could you remove those
two methods, then add corresponding set() methods to IdentityType
(04:41:47 PM) psilva1: sbryzak: i agree we may loose the lazy thing ..
if the have not loaded the U/R/G before (just used new SimpleUser, for
example). But i think it is better ..
(04:41:51 PM) psilva1: sbryzak: ok ..
(04:41:58 PM) psilva1: sbryzak: going to do that ..
(04:42:05 PM) sbryzak: they shouldn't be using new SimpleUser() for that
kind of operation
(04:42:15 PM) sbryzak: they should lookup the User object by using
getUser() first
(04:42:28 PM) psilva1: sbryzak: yeah ... but users are users .. if they
can they will do it ... :)
(04:42:54 PM) psilva1: sbryzak: did you think about the attribute
methods on the IM interface ?
(04:42:58 PM) misty [misty@redhat/jboss/misty] entered the room.
(04:43:50 PM) sbryzak: um, yes
(04:44:01 PM) psilva1: what is the veredict ? :)
(04:44:23 PM) sbryzak: i don't have a solid conclusion yet
(04:44:45 PM) psilva1: ok, no problem .. going to work with the
enable/expiration stuff ... thanks ..
(04:44:48 PM) sbryzak: i like those methods because they're
deterministic, i.e. you know exactly what to do when they're called
(04:44:57 PM) psilva1: ok
(04:45:26 PM) sbryzak: if we just use update(), then we first need to
read all of the user's attributes, determine which ones have been
deleted, updated, or removed, then update the records accordingly
(04:45:48 PM) sbryzak: i guess we have to do that anyway if we're
introducing an update() method
(04:46:11 PM) psilva1: sbryzak: yeah .. going to say that ... i have to
do something similar for the ldap store ...
(04:46:12 PM) sbryzak: ok, there's one problematic use case i just
thought of
(04:46:22 PM) sbryzak: what if an attribute is lazy loaded
(04:46:26 PM) psilva1: i had to do .. because it is done already ..
(04:46:29 PM) psilva1: ok
(04:46:40 PM) sbryzak: so you call getUser() to get the User instance
(04:46:45 PM) psilva1: ok
(04:46:48 PM) sbryzak: the lazy-loaded attribute isn't loaded by default
(04:46:55 PM) sbryzak: then you add a new attribute to the user
(04:46:59 PM) sbryzak: then call update(user);
(04:47:22 PM) sbryzak: how will we know whether the attribute has been
removed by the User, or just hasn't been loaded yet?
(04:47:50 PM) psilva1: sbryzak: i think that depends on the store impl ...
(04:47:52 PM) balunasj|mtg left the room (quit: Quit: Linkinus -
http://linkinus.com).
(04:48:28 PM) psilva1: sbryzak: for JPA it will not be removed, if the
user provided a attached instance ...
(04:50:01 PM) psilva1: sbryzak: for LDAP, i'm always considering the
attributes (only the custom attributes, not the managed - ldap
internal/schema - ones) list provided with the updated instance ...
(04:50:08 PM) sbryzak: so the question really is, how do we handle lazy
loaded attributes
(04:51:51 PM) psilva1: for JPA it is already handled by the impl such as
hibernate, right ? Depending of course how the user mapped his entities ...
(04:52:03 PM) sbryzak: not really
(04:52:16 PM) sbryzak: the identity store implementation needs to handle
it itself
(04:52:33 PM) sbryzak: ok, let's look at a concrete example
(04:52:39 PM) psilva1: ok
(04:52:42 PM) sbryzak: say there's an attribute called userImage
(04:52:53 PM) sbryzak: and it contains a really long byte array, and
it's marked as lazy loaded
(04:53:16 PM) sbryzak: when you call IdentityManager.getUser("bob"),
you'll get a User instance that doesn't have the userImage attribute loaded
(04:53:36 PM) sbryzak: but it may have other non-lazy attributes loaded,
for example dateOfBirth
(04:53:57 PM) psilva1: first question .. how an attribute is marked as
lazy with the IDM API ?
(04:54:23 PM) sbryzak: that's a good question - it's something we
haven't implemented yet, only talked about
(04:54:27 PM) psilva1: :)
(04:54:35 PM) sbryzak: i imagine we'll add a "lazyLoaded" property to
the Attribute class
(04:55:06 PM) sbryzak: so, for the next step of our use case, we call
User.setAttribute("foo", "bar")
(04:55:19 PM) sbryzak: then our User has two attributes, dateOfBirth and foo
(04:55:55 PM) sbryzak: we then call IdentityManager.update(user)
(04:56:23 PM) sbryzak: the IdentityStore can see that dateOfBirth hasn't
changed (by reading in the current value from storage) so it won't
update that attribute
(04:56:41 PM) sbryzak: it can tell that foo is a new attribute, so it
will create it
(04:56:57 PM) sbryzak: it can also see that userImage is no longer in
the User's attribute list
(04:57:12 PM) sbryzak: so this is the issue..
(04:57:28 PM) sbryzak: in normal circumstances if an attribute isn't
there, we would delete it
(04:57:51 PM) sbryzak: but in this use case it isn't there because it's
lazy loaded, not because the user has explicitly removed it
(04:58:11 PM) psilva1: if you going to add a lazyloaded property to the
Attribute class, maybe you can put a flag indicating where it was loaded
or not ... if yes, consider what is setted (if null remove, for example) ...
(04:58:35 PM) psilva1: otherwise update it ...
(04:58:45 PM) psilva1: if the value changed, of course ..
(04:59:00 PM) sbryzak: i think we're missing something here
(04:59:19 PM) sbryzak: how do we get a list of all user attributes that
have been set?
(04:59:24 PM) sbryzak: we don't have support for that in IdentityManager
(04:59:34 PM) psilva1: sbryzak: just going to say that before you start
telling the use case ...
(04:59:43 PM) psilva1: sbryzak: we need some kind of metadata ....
(05:00:02 PM) psilva1: sbryzak: for attributes .. so that we can know
which attributes are lazy or not ...
(05:00:14 PM) sbryzak: ok i have an idea
(05:00:24 PM) sbryzak: 1) we add a lazyLoaded property to Attribute
(05:01:02 PM) sbryzak: 2) we replace IdentityManager.getAttribute() with
IdentityManager.loadAttribute(IdentityType, String)
(05:01:22 PM) sbryzak: what 2) does is load a lazy attribute value into
the User object
(05:01:27 PM) sbryzak: er, IdentityType object
(05:02:05 PM) sbryzak: so when you call IdentityManager.getUser(), you
get a User object with all the Attribute values set
(05:02:34 PM) sbryzak: however for the lazy loaded ones, isLoaded() will
return false and getValue() will return null
(05:02:56 PM) sbryzak: for these ones, if you want to load the value you
can e.g. call im.loadAttribute(user, "userImage")
(05:03:17 PM) sbryzak: then, user.getAttribute("userImage").getValue()
will return a non-null value
(05:03:35 PM) sbryzak: how does that sound?
(05:04:14 PM) psilva1: sbryzak: yeah, but i did not understand yet how
you going to check if an attribute is lazy or not when calling
getUser/Role/Group, for example ...
(05:04:30 PM) sbryzak: that's simple
(05:04:45 PM) sbryzak:
im.getUser("bob").getAttribute("userImage").isLoaded();
(05:05:54 PM) sbryzak: in fact, i don't think we need a
Attribute.lazyLoaded property
(05:06:05 PM) sbryzak: we just need to provide an isLoaded() method and
nothing else
(05:06:31 PM) psilva1: sbryzak: ok, i understood that, the isLoaded()
method ... but when loading the user and his attributes you need to
check for each attribute where it is lazy or not .. otherwise you going
always to load everything ...
(05:06:50 PM) psilva1: maybe i'm missing something around what you said ....
(05:06:50 PM) sbryzak: that's controlled by metadata
(05:07:06 PM) psilva1: sbryzak: ahhh .. that was my point :)
(05:07:15 PM) sbryzak: so in the JPA case, we have an annotation called
org.picketlink.idm.jpa.annotations.IDMAttribute
(05:07:28 PM) sbryzak: we simply add a boolean lazy() default false;
member to that annotation
(05:07:29 PM) psilva1: ok
(05:07:51 PM) psilva1: sbryzak: let's use the ldap store in the example ..
(05:08:12 PM) sbryzak: for LDAP, i guess you need to define the metadata
some other way
(05:08:28 PM) psilva1: sbryzak: yeah ... that is what i'm trying to
think ...
(05:08:48 PM) sbryzak: either make it an automatic decision based on the
type or size of the attribute value
(05:08:55 PM) psilva1: sbryzak: maybe, for LDAP, the lazy feature does
not makes much sense ...
(05:09:03 PM) sbryzak: or have it defined in the LDAPConfiguration somehow
(05:09:11 PM) psilva1: sbryzak: yeah ...
(05:09:57 PM) sbryzak: that still leaves the question about
IdentityManager.setAttribute() and removeAttribute()
(05:10:03 PM) sbryzak: possibly we can removed these methods now
(05:10:18 PM) sbryzak: especially if we're going to support them via the
update() method anyway
(05:10:47 PM) psilva1: sbryzak: nice ...
(05:10:53 PM) psilva1: sbryzak: going to do that too ..
(05:10:57 PM) psilva1: sbryzak: just wondering why an user would use the
IDM lazy feature (when using JPA) and not what JPA provides ....
(05:11:22 PM) sbryzak: it all depends on how the attribute data is stored
(05:11:32 PM) sbryzak: remember it can be spread across multiple tables
(05:11:55 PM) sbryzak: and it is expensive to load in a large blob value
(05:11:57 PM) ***asaldhan is following the discussion silently
(05:12:08 PM) sbryzak: hey anil
(05:12:33 PM) asaldhan: sbryzak: hey. need my inputs on MD?
(05:12:39 PM) psilva1: sbryzak: asaldhan: what do you think about we
discussed ?
(05:12:43 PM) sbryzak: i'm wondering if we should add an isDirty()
method to Attribute also
(05:13:33 PM) asaldhan: psilva1: sbryzak: adding the methods to
attribute is fine as long as the default behavior is to load everything
and there is no laziness required.
(05:13:52 PM) asaldhan: psilva1: sbryzak: the methods will take care of
the 10% of users who want total control
(05:14:03 PM) sbryzak: asaldhan: of course, you would have to explicitly
mark an attribute as lazy if you wanted it lazy loaded
(05:14:09 PM) sbryzak: default behaviour is to just load everything
(05:14:11 PM) asaldhan: sbryzak: right.
(05:14:56 PM) asaldhan: sbryzak: that should be fine. :) having the IDM
API extensible and comprehensive is a good objective. But default IMO
should be simplicity. I think sbryzak agrees to that strategy
(05:15:01 PM) sbryzak: psilva1: i'll update the Attribute class, did you
want me to update the attribute methods in IdentityManager also?
(05:15:35 PM) psilva1: sbryzak: let'me handle the IM .. i need to remove
the setEnable/Expiration anyway ... give a minute .. ok ?
(05:15:43 PM) sbryzak: sure thing
(05:15:44 PM) asaldhan: psilva1: I think Shane is future proofing the API.
(05:16:06 PM) psilva1: asaldhan: sbryzak: yeah ... maybe we should have
this feature on next releases ...
(05:16:09 PM) sbryzak: i just don't want to still be working on this in
a year from now ;)
(05:16:30 PM) asaldhan: psilva1: yeah it can be in the API.
(05:16:37 PM) asaldhan: psilva1: not implemented in the first release
(05:18:27 PM) psilva1: sbryzak: do you want me to rename the
getAttribute to loadAttribute too ?
(05:19:16 PM) sbryzak: psilva1: yes please, and make it a void method
(05:19:21 PM) psilva1: sbryzak: ok
(05:19:38 PM) sbryzak: psilva1: let me know when it's committed and i'll
make the changes to Attribute
(05:19:43 PM) psilva1: ok
(05:24:05 PM) psilva1: sbryzak:
https://github.com/picketlink/picketlink/pull/14
(05:24:11 PM) asaldhan: user.getAttribute exists?
(05:24:22 PM) psilva1: yes ..
(05:25:01 PM) sbryzak: psilva1: looking good
(05:25:09 PM) psilva1: nice
(05:25:31 PM) psilva1: sbryzak: it is merged ..
(05:25:32 PM) sbryzak: afk for a little bit, need to make a phone call
(05:25:37 PM) sbryzak: psilva1: thanks
(05:26:08 PM) asaldhan: psilva1: I will always do im.getuser() and
then just use the methods on the User instance
(05:26:21 PM) asaldhan: psilva1: and persist using IM
(05:27:00 PM) psilva1: asaldhan: as you said ... 90% of users would
prefer that ... but always have some smart ones with different use cases ...
(05:27:15 PM) asaldhan: psilva1: right.
(05:27:24 PM) asaldhan: psilva1: people will just follow the documentation
(05:27:43 PM) psilva1: yeah :)
(05:28:10 PM) asaldhan: psilva1:
https://docs.jboss.org/author/display/PLINK/PicketLink+IDM
(05:28:19 PM) asaldhan: psilva1: that is where the doc will be for IDM
(05:30:48 PM) psilva1: ok
(05:32:11 PM) psilva1: asaldhan: sbryzak: i was thinking about the LDAP
store x attributes ... maybe we can put some configuration to load only
a set of attributes by default (user defined). LDAP entries can have a
lot of attributes. Maybe limiting that can be good for performance
reasons ....
(05:33:10 PM) psilva1: asaldhan: sbryzak: as LDAP does not have the JPA
lazy support ....
(05:33:27 PM) asaldhan: psilva1: we can revisit that when we see a lot
of ldap usage
(05:33:35 PM) asaldhan: psilva1: Bolek can answer that.
(05:34:04 PM) psilva1: asaldhan: nice, going to open a discussion on the
list for that ...
(05:35:14 PM) asaldhan: psilva1: when will u start with JPA tests?
(05:36:15 PM) psilva1: asaldhan: when sbryzak release the store ... now
i'm adding the enable and expiration (and implementing) to the test
cases ...
(05:37:12 PM) psilva1: asaldhan: i'm using the ldap store to code the
tests. After that is a matter of configuring a JPA test suite with the
test cases i'm writing.
(05:37:14 PM) asaldhan: psilva1: I am only thinking of updating the document
(05:37:22 PM) asaldhan: psilva1: I mean article
(05:43:18 PM) psilva1: sbryzak: pushed the setEnabled and
setExpirationDate to the IdentityType.
(05:51:39 PM) sbryzak: asaldhan: i'd like to create docbook based
documentation for picketlink
(05:52:10 PM) sbryzak: that way we can upload it to the picketlink
project site, or users can download it as part of the picketlink
distribution
(06:01:32 PM) sbryzak: psilva1: i'm wondering if the Attribute.unique
property is actually useful
(06:01:56 PM) sbryzak: i'm actually inclined to think it isn't
(06:02:03 PM) psilva1: sbryzak: let somebody ask for it :)
(06:02:21 PM) psilva1: sbryzak: i agree ...
(06:02:50 PM) sbryzak: i think if anything it should be handled at a
lower level by metadata, not by the Attribute class itself
(06:02:58 PM) sbryzak: ok, i've removed it
(06:03:34 PM) psilva1: sbryzak: maybe attributes are unique by nature ...
(06:03:48 PM) sbryzak: well no, two people could have the same date of birth
(06:04:00 PM) sbryzak: i think it's more intended to prevent duplicate
attribute values like e-mail addresses
(06:04:03 PM) sbryzak: or social security numbers
(06:04:06 PM) sbryzak: something like that
(06:04:54 PM) psilva1: sbryzak: i only considered the name ... not the
value ... sorry ..
(06:08:47 PM) psilva1: sbryzak: and the user can control that ....
application specific ...
(06:25:06 PM) psilva1: sbryzak: asaldhan: some status report ... the
following features are covered by the tests: createUser, readUser,
updateUser, deleteUser, createGroup, readGroup, updateGroup,
deleteGroup, createRole, readRole, updateRole, deleteRole,
disable/enable U/R/G, expiry U/R/G, add/remove/update attributes for U/R/G.
(06:25:14 PM) psilva1: considering the LDAP store ...
(06:35:29 PM) sbryzak: psilva1: great work
(06:35:56 PM) psilva1: sbryzak: for us :)
(06:35:57 PM) sbryzak: psilva1: could you possibly add a jpa config to
the test suite?
(06:36:06 PM) psilva1: sbryzak: sure ..
(06:36:27 PM) sbryzak: psilva1: just leave it on @Ignore for now if you like
(06:36:30 PM) psilva1: sbryzak: after that i'm going to work with
credentials ... that way we provide a "complete" workflow ...
(06:36:34 PM) sbryzak: that way i can enable it to run the tests
(06:36:49 PM) sbryzak: see where the jpa store has issues
(06:37:22 PM) psilva1: sbryzak: ok . i've already added the suite ..
just going to leave the suite running with a configured PU ...
(06:37:46 PM) asaldhan: psilva1: can u update the confluence with the
examples like I have done?
(06:38:37 PM) psilva1: asaldhan: i still have some things to work on ...
like the credential stuff ... that way we can have a "complete" usage
workflow ... with the basic features ...
(06:38:39 PM) asaldhan: sbryzak: docbook should be ok for documentation.
(06:38:56 PM) asaldhan: psilva1: we use confluence to showcase simple
usecases
(06:38:59 PM) psilva1: asaldhan: or you really want to do the docs now ?
(06:39:19 PM) psilva1: asaldhan: nice ..
(06:39:33 PM) asaldhan: psilva1: the IDM confluence just shows CRUD stuff.
(06:39:45 PM) psilva1: asaldhan: is not better to centralize the docs ?
(06:39:51 PM) asaldhan: psilva1: to get people started on something. the
overall doc can be in docbook
(06:39:58 PM) psilva1: ok
(06:40:20 PM) psilva1: asaldhan: let me finish the credential stuff and
i start to work with the docs, ok ?
(06:40:29 PM) asaldhan: k
(06:40:55 PM) psilva1: asaldhan: i'm not running away from the docs :)
(06:41:19 PM) asaldhan: psilva1: no. I meant the
https://docs.jboss.org/author/display/PLINK/PicketLink+IDM
(06:41:34 PM) asaldhan: psilva1: that is just like 10m work - copy paste
from testsuite
(06:41:43 PM) psilva1: asaldhan: just kidding ... i'll do that ...
(06:41:54 PM) asaldhan: psilva1: that can be done tomm
(06:42:00 PM) psilva1: k
(06:42:59 PM) psilva1: asaldhan: btw, did you see the changes to the
LDAP store ?
(06:44:28 PM) psilva1: asaldhan: tried to leave the store only with the
IDM logic and LDAP stuff decoupled. Maybe we can have a component for
picketbox-ldap (LDAPOperationManager).
(06:44:42 PM) asaldhan: psilva1: looking at ldap store changes
(06:46:38 PM) asaldhan: psilva1: the operation mgr is fine
(06:47:39 PM) psilva1: asaldhan: need to put you as an author, most of
the code is yours :) doing that ..
(06:48:15 PM) asaldhan: psilva1: I dont sweat that anymore. :)
(06:48:23 PM) asaldhan: psilva1: my legacy is enough.
(06:48:37 PM) psilva1: LOL
(06:49:11 PM) sbryzak: @author tag lets people know who to blame ;p
(06:50:03 PM) ***asaldhan is afk for 1 hr
(06:53:52 PM) psilva1: sbryzak: :). btw, did the same thing you did
regarding the config for the ldap store (decoupled from the store).
(06:55:12 PM) sbryzak: psilva1: great, that was an important thing to
get done
(06:55:38 PM) psilva1: sbryzak: do you want an different EMF for each
test method or a shared one ?
(06:55:54 PM) psilva1: for the jpa suite ..
(06:57:21 PM) sbryzak: psilva1: i'm not sure it matters
(06:57:28 PM) psilva1: ok
(06:57:29 PM) sbryzak: perhaps a different one
(06:57:38 PM) sbryzak: that way we start with a new persistence context
each time
(07:19:03 PM) psilva1: sbryzak: jpa suite is configured ...
(07:19:21 PM) psilva1: sbryzak: first gap is features not set :)
(07:20:28 PM) psilva1: sbryzak: for each test method a entitymanager
instance should be created and a transaction started. After the method
finish the transaction will be commited and the entitymanager closed.
(07:21:19 PM) psilva1: sbryzak: asaldhan: need to go now ... cya
tomorrow. thanks.
(07:21:40 PM) psilva1 left the room (quit: Quit: Leaving.).
13 years, 10 months
PicketLink License will be ASL
by Anil Saldhana
Hi all,
I have approval for the change of license for PicketLink to ASLv2.
The development work happening for PicketLink v3 right now will include
change of license headers etc.
Thanks to Pete Muir for the help.
Regards,
Anil
13 years, 10 months
PicketLink Capabilities - Authentication
by Darran Lofthouse
Hello all,
Just looking at how I could make use of PicketLink withing AS7 and have
a couple of questions.
For Digest based authentication mechanisms I see there is some initial
support but I have a couple more requirements I will raise separately.
The next area I am looking into is SSL and Client Cert style
authentication - a couple of things I am interested in here is - is
there a capability to take a certificate, validate it and then return
the identity of the user from that certificate? i.e. I am not looking
to load the user first and then validate the certificate.
Secondly in this area could it be conceivable to implement a
X509TrustStore that is backed by PicketLink? If we could obtain all
validate certificates or the certificate of a CA we could create
somethign in advance but I am interested in if we could have something
more dynamic.
Following on from this I have one more case that I am not sure if it
would fit within an IDM or if we would handle it outside first and only
access the IDM once we have verified the user and that is GSSAPI/SPNEGO
style authentication. In this case we receive one or more tokens from a
user and send one or more challenges back to the user - at the end of
this authentication process we know the identity of the user.
Also interested in knowing if anyone else has other authentication
scenarios identified where all we may have is the 'Credential' and the
user is not identified until after this has been verified.
Regards,
Darran Lofthouse.
13 years, 10 months
SOA Governance Overlord needs IDM
by Anil Saldhana
Guys,
I was chatting with Kurt Stam today and he has immediate needs for
IDM/LDAP. I know Kevin is on this list. Kurt will probably join the list.
FYI.
Regards,
Anil
13 years, 10 months
IDM API - Final review
by Shane Bryzak
I've updated the IdentityManager API based on the latest design, could
everyone please take a couple of minutes to review and let me know if
you spot any issues. We'll probably do a time-boxed release (Anil,
could you please confirm?) shortly so that projects consuming PLIDM can
start building against the API.
Thanks,
Shane
public interface IdentityManager {
void bootstrap(IdentityConfiguration configuration,
IdentityStoreInvocationContextFactory contextFactory);
void setIdentityStoreFactory(IdentityStoreFactory factory);
// User
void createUser(User user);
void removeUser(User user);
void updateUser(User user);
User getUser(String name);
// Group
void createGroup(Group group);
void removeGroup(Group group);
Group getGroup(String groupId);
Group getGroup(String groupName, Group parent);
boolean isMember(IdentityType identityType, Group group);
void addToGroup(IdentityType identityType, Group group);
void removeFromGroup(IdentityType identityType, Group group);
// Roles
void createRole(Role role);
void removeRole(Role role);
Role getRole(String name);
boolean hasRole(IdentityType identityType, Role role, Group group);
void grantRole(IdentityType identityType, Role role, Group group);
void revokeRole(IdentityType identityType, Role role, Group group);
boolean hasApplicationRole(IdentityType identityType, Role role);
void grantApplicationRole(IdentityType identityType, Role role);
void revokeApplicationRole(IdentityType identityType, Role role);
// Query API
<T extends IdentityType> IdentityQuery<T> createQuery();
// Credential management
boolean validateCredential(User user, Credential credential);
void updateCredential(User user, Credential credential);
// User / Role / Group enablement / expiry
void setEnabled(IdentityType identityType, boolean enabled);
void setExpirationDate(IdentityType identityType, Date expirationDate);
IdentityType lookupIdentityByKey(String key);
// Attributes
void setAttribute(IdentityType identityType, Attribute<? extends
Serializable> attribute);
<T extends Serializable> Attribute<T> getAttribute(IdentityType
identityType, String attributeName);
void removeAttribute(IdentityType identityType, String attributeName);
// Realm
void createRealm(Realm realm);
void removeRealm(Realm realm);
Realm getRealm(String name);
// Tier
void createTier(Tier tier);
void removeTier(Tier tier);
Tier getTier(String id);
// Context
IdentityManager forRealm(Realm realm);
IdentityManager forTier(Tier tier);
}
13 years, 10 months
