[00:02:16 EDT(-0400)] * andrew_petro_ubu (n=apetro@71-223-119-61.phnx.qwest.net) has joined ##uportal
[00:02:28 EDT(-0400)] <andrew_petro_ubu> kinda lonely in here...
[01:28:42 EDT(-0400)] <andrew_petro_ubu> Any good reason I wouldn't be able to sftp into www.ja-sig.org : Status: Connection established, waiting for welcome message...
[01:28:42 EDT(-0400)] <andrew_petro_ubu> Error: Could not connect to server
[03:07:27 EDT(-0400)] * apetro_win_home (n=andrew_p@ip68-99-92-218.ph.ph.cox.net) has left ##uportal
[03:07:37 EDT(-0400)] * apetro_win_home (n=andrew_p@ip68-99-92-218.ph.ph.cox.net) has joined ##uportal
[09:21:25 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[10:15:09 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:17:31 EDT(-0400)] <esm> EricDalquist: hey got a sec
[10:17:42 EDT(-0400)] <EricDalquist> sure
[10:18:00 EDT(-0400)] <esm> so... on this ldap thing
[10:18:11 EDT(-0400)] <esm> backing up, I took a look at users in general in up3
[10:18:22 EDT(-0400)] <EricDalquist> ok
[10:19:53 EDT(-0400)] <esm> so there is an acegi authentication provider, used on login, and there is another user controller with "acegi" in the classname used by the portal common context code
[10:20:15 EDT(-0400)] <EricDalquist> sounds like what I remember
[10:20:37 EDT(-0400)] <esm> the acegi authentication provider is totally vanilla, and actually looks at the "user" and "authorities" column of the db.
[10:20:49 EDT(-0400)] <esm> the UserDaoImpl (used by the context code) looks at UP_USER
[10:20:55 EDT(-0400)] <EricDalquist> yeah
[10:21:15 EDT(-0400)] <EricDalquist> so the UserDaoImpl is what ties the acegi generated principal with uP3's concept of a user
[10:21:26 EDT(-0400)] <esm> so i'm wondering the best way to proceed. those divergent approaches need to be merged, right?
[10:21:29 EDT(-0400)] <esm> ok
[10:21:43 EDT(-0400)] <EricDalquist> so you would swap the acegi auth config to go against ldap
[10:21:49 EDT(-0400)] <esm> right
[10:22:00 EDT(-0400)] <esm> no prob there
[10:22:10 EDT(-0400)] <EricDalquist> and then the next step would be to update the UserDaoImpl and perhaps some UserDao client code logic to deal with users that don't actually exist yet
[10:22:23 EDT(-0400)] <EricDalquist> I'm thinking you'll only need to update UserDaoImpl
[10:22:43 EDT(-0400)] <EricDalquist> so that it is smart enough that if a user being asked about doesn't exist it creates the uP3 user object and persists it
[10:23:21 EDT(-0400)] <esm> ok i think i get it
[10:23:56 EDT(-0400)] <EricDalquist> UserDao is really more of a mapping
[10:24:29 EDT(-0400)] <EricDalquist> from acegi generated principal IDs to the internal User object (really represented by the generated key in the table that UserDaoImpl uses)
[10:27:14 EDT(-0400)] <esm> ok i guess i what was confusing to me was that acegi's authentication providers are looking in one place for authentication (e.g. the USER table) and then the AcegiSessionUserController is using the UserDaoImpl to get user info from aonther place.
[10:28:09 EDT(-0400)] <esm> UP_USER
[10:28:21 EDT(-0400)] <esm> the apache ds plugins for eclipse are nice
[10:28:23 EDT(-0400)] <EricDalquist> yeah
[10:28:32 EDT(-0400)] <EricDalquist> so the USER table represents LDAP
[10:28:45 EDT(-0400)] <EricDalquist> just some source of user credentials
[10:28:51 EDT(-0400)] <esm> ok
[10:28:53 EDT(-0400)] <EricDalquist> the portal framework never looks at it
[10:29:02 EDT(-0400)] <esm> at some point that has to be updated to be encrypted and stuff right?
[10:29:03 EDT(-0400)] <EricDalquist> UP_USER is the list of users the portal 'knows' about
[10:29:08 EDT(-0400)] <EricDalquist> yeah
[10:29:08 EDT(-0400)] <EricDalquist> well
[10:29:19 EDT(-0400)] <EricDalquist> yeah it would
[10:29:34 EDT(-0400)] <EricDalquist> but if we use ApacheDS as the default
[10:29:39 EDT(-0400)] <esm> right
[10:29:40 EDT(-0400)] <EricDalquist> that table would just go away
[10:29:49 EDT(-0400)] <EricDalquist> in favor of whatever DS uses for its backing store
[10:30:07 EDT(-0400)] <esm> ok so another question - i don't see anywhere in uP3 where users are actually created
[10:30:19 EDT(-0400)] <esm> up3 seems to assume that users are already "there"
General
Content
Integrations