[security-dev] IDM Design Session : IRC Chat Transcript

[Anil Saldhana]

(04:45:19 PM) psilva [~pedroigor at 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/e1e3220f5c510ca5cca20e931810f955c3375ab6
(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 at 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 at 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 at 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 at 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 at 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.).