Re: modeling problem
Re: modeling problem
- Subject: Re: modeling problem
- From: Tim Worman <email@hidden>
- Date: Thu, 2 Apr 2009 08:50:10 -0700
Daniel:
I have group authorization working. I haven't looked at Chuck's
classes yet but I know I am using some methods that Chuck shared for
handling LDAP multi-values. To determine group membership I am using
PosixGroup.memberUid(). That is a multi-value attribute. The code I'm
using converts it to NSArray then I defined these:
simplified version
LDAPUser {
public boolean isMemberOfGroup(String groupname) {
//get group where cn.equals(groupname)
return resultingGroup.hasMember(this.uid());
}
}
PosixGroup {
public boolean hasMember(String username) {
return this.memberUid().contains(username);
}
}
What I'd really like to do though is model AppleGroup to inherit from
PosixGroup - the way it really does in ldap. AppleGroup has some
additional attributes that could be useful down the road. I know there
is someone on-list who has gone down the road of better representing
the structure of ldap in their model and at some point I'm going to go
back and look at their posts again.
T
On Apr 1, 2009, at 7:33 PM, Chuck Hill wrote:
On Apr 1, 2009, at 4:51 PM, Daniel Beatty wrote:
Greetings Tim,
So far it seems you and I are hitting the same problem. There is
one additional question regarding the modeling of InetOrgPerson as
defined in the OD scheme. How does it reference the "User" with
groups defined on the OD? For annoying things like authorizing a
person to use a resource, it would be nice to let OD do "its thing"
to determine group membership.
I would certainly appreciate some insight. Also, it was nice to
notice that the InetOrgPerson includes references to User
Certificates, which is more useful in determining membership to a
particular federation.
Handling some of the LDAP data can be interesting. I will attach
three classes related to how group membership is determined in
GVC.SiteMaker. It has been years since I worked on this.
Chuck
<LDAPBranch.java>
<LDAPGroupRecord.java>
<LDAPGroup.java>
Later,
Dan Beatty, M.S. CS (B.S. EECS)
Ph.D. Student
Texas Tech University
email@hidden
http://venus.cs.ttu.edu/~dabeatty
On Mar 31, 2009, at 4:33 PM, TW wrote:
On Mar 31, 2009, at 10:06 AM, Chuck Hill wrote:
On Mar 30, 2009, at 4:29 PM, TW wrote:
My goal was to have an entity/class (where InetOrgPerson is
super) in a "middle" framework that can be used to wrap a
relationship between ldap user and database employee (each
modeled in their own frameworks). So, the way I have it set
up there's really no difference between InetOrgPerson and
GenericUser except that GenericUser has the relationship to
<database employee> and InetOrgPerson does not.
I still wonder if GenericUser should have a relationship to
both InetOrgPerson and DatabaseEmployee.
With that approach, it sounds like GenericUser would have to
have it's own data table separate from the other two?
Doesn't it need to anyway for the relationship to
DatabaseEmployee?
Not really. Time for ascii sheep. This is what I have.
LDAPModel ---to build path--> UserModel <--to build path----
DBModel
======== ========= ================
InetOrgPerson GenericUser <-------------> Employee
(InetOrgPerson/parent)
The only relationship (on the right) uses "employee_id."
That is in the LDAP information?
Yes, InetOrgPerson has "employeeNumber." We use FileMaker-based
tools I created for adding accounts to OD. They call DSImport to
add records to OD as needed and they're set up to push the
employee_id into that attribute.
Actually, there's a scenario right there that supports your
suggestion to have an intermediary GenericUser table since that is
essentially the same position the old FileMaker database holds -
collection of "everyone."
This approach makes the ldap side of things the starting point
since that is the store that knows what type of user the person
is. If ldap authentication is successful, I query for the
matching GenericUser which is essentially an ldap person since
GenericUser inherits from InetOrgPerson.
That sounds like a correct use of inheritance. I think you are
going to need a restricting qualifier on InetOrgPerson that is
always false.
I tried the (1=0) restricting qualifier and EOGenerator did not
like it and coughed up an error about being unable to parse the
qualifier. Good thought though.
Well, I've got a version in my repository the way it is. I'm
trying to model it the other way around now and we'll see how that
works.
Then, I can test for the related employee record. If there, foo,
if not, bar - depends on the app.
It sounds like your preferred approach would be to create
another table for GenericUser making it a database entity
instead of inheriting from InetOrgPerson. That could work too.
The problem there is then I have two entities, InetOrgPerson and
GenericUser that have to have similar attributes, including
"usertype," "email," etc. And, when a new Employee is created,
I'd have to force the creation of a GenericUser.
It sounds like you are on the right track. I think.
I can see advantages each way and it's too bad I'm somewhat at
the mercy of the greater campus.
Hence the lure of herding goats and sheep, living on wine and
cheese.
Chuck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden