OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FW: [provision] Re: Domain Model for Identity Management (Standard Schema ERD).

Hi Gary,

I reviewed the Schema ERD document and found your entity and
relationship descriptions for Organization, Person, Account, Group and
Role very helpful and comprehensible. 

However, I agree with Jeff that the definition of provisioning entities
that relate to access control like Host, TypeOfAccount and Privilege
would be out of scope for the Standard Schema. Besides the risk of
re-inventing existing policy frameworks, I see a problem in syncing this
data and keeping it up to date between the PSP and the PST. Wouldn't it
be in the interest of the PST's administrator to hide the complexity of
the access privileges and infrastructure details and expose only the
role names to the PSP?

With respect to Jeff's comment on the distinction between Person and
Account, my way of assigning attributes to one or the other entity would
be that "Person" attributes are directly connected to a natural person
(name, company address, other addresses, location within company, e-mail
and other contact data, etc.) whereas the "Account" entity refers to the
set of attributes that are controlling the Person's access to a system
(technical attributes like account locked flag, expiry date etc.)

Best regards

-----Original Message-----
From: Bohren, Jeff [mailto:Jeff_Bohren@BMC.com] 
Sent: Dienstag, 2. Mai 2006 16:39
Subject: RE: [provision] Re: Domain Model for Identity Management
(Standard Schema ERD).


I did review this and planned to discuss this on the call today. My
thoughts are:

I don't think we want to introduce policies into this schema (the Host
and Privilege object classes and their associated references). I don't
think it is feasible to devise a policy schema that is generic enough
for the Standard schema. If we want to address policy then we should
look at possibly using XACML. Or possibly it should be another scheme
that depends on this schema.

The TypeOfAccount object class is unnecessary in the DSML profile as all
DSML objects have an object class (which can be multi-valued). This is
an interesting issue because this is the first case in which we have a
profile specific part of the schema. 

There should be an associate between roles and groups. In other words a
group can have a role just like a person can have a role.

We need to better distinguish between Person and Account objects. They
should not have the same attributes.

Jeff B.
-----Original Message-----
From: Gary.P.Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Tuesday, May 02, 2006 9:33 AM
Subject: [provision] Re: Domain Model for Identity Management (Standard
Schema ERD).

I haven't seen any comment on the list about this information model.  
So, what does this mean?
A) Everyone loves it (and thinks it's just great as-is)?
B) Everyone hates it (but cannot bring themselves to say so)?
C) Everyone's busy with something else?
D) Sun's mail servers discarded all the replies that came to the list?

I'm glad to work on this, but I don't want to go too far beyond what is 
generally agreed.  (That would  seem to be bad in an effort aimed at 

Gary.P.Cole wrote:
> Jeff Bohren asked me to provide an Entity-Relationship Diagram (ERD) 
> for the entities we've been discussing as part of the standard schema 
> for SPML.  I'm really glad that he did, because re-thinking those 
> entities and relationships was a good exercise. I found that I went 
> further than before, and I'm very interested to see whether we agree 
> (and the extent to which we can agree) on this domain model.
> Most of this domain model is the same as it was before, although it is

> perhaps clearer when properly articulated as an ERD with ordinality, 
> cardinality, direction and so forth. Person and Account are the same; 
> Group, Organization and Role are the same.  The area that is new has 
> to do with Role and Type-of-Account.  A Role may imply any number of 
> types of account for a host.  Each type of account may confer 
> privileges on that host.
> I'm afraid that I may miss today's meeting.  (Unfortunately, I have a 
> conflict.)  However, I'd be very excited to take questions and 
> comments on the list.  Once everyone's had a chance to read it, we can

> decide whether to discuss it during the next call.   (If everyone 
> hates it, we can decide whether to back up and revert to the areas 
> previously defined.  If everyone basically likes it, we can discuss 
> details like the specifics of entities, relationships, attributes and 
> names.)
> I've attached a draft of the document (with everything removed except 
> the domain model sections).  This is an OpenOffice 2.0 document, which

> may be weird for some people, so I've also attached it as a PDF.  
> Hopefully one format or the other will work for everyone.
> Gary

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]