[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [cmis] RE: question re Users for repository vendors
Hi David and Bram, from consumer view, we
have a (not exact the same but) similar problem. Setting ACL through CMIS
is deficient for our application since we have only one ID (principal-Id) to associate with an ACL,
most use cases in our application need the possibility to provide group- instead of user-ID for
ACL. Although it is not mentioned
what the principal-ID is, one of the user-group or the current user ID! An enhancement like you
mention would help a lot also for the consumer/clients. Maybe one part of the enhancement
could be that it will be possible to return more information about the current logged
in user, like (DisplayName, ShortName,…). Currently we solving the
user information issue through bypassing the CMIS and using LDAP to get more information,
but if there are more vendors having the same construct like HP Trim it will be an issue for
us again. So from my side I’m
extremely interested into the new enhancement/feature you proposing! Kind Regards,
WeWebU Software AG T: +49 (9132) 83660 - 13 http://www.wewebu-software.com Sitz / Domicile: Herzogenaurach,
Deutschland Vertretungsberechtigter Vorstand /
Executive Board: Aufsichtsrat / Supervisory Board: Michael
Salleck (Vorsitzender / Chairman) Registergericht / Register Court: Fürth,
Bay. Von: Churchland,
David [mailto:david.churchland@hp.com] Bram, The options you have canvassed are
pretty much the same as the options I have considered. As you identify
the first option is possible today but not particularly useful given that it is
not described by the standard and would thus be invisible to consumers. If CMIS does embrace Jay’s ‘super
type’ I can imagine the spec describing an optional user/group base type,
this might be one way forward. To clarify, the problem I have is that
as our Groups are not necessarily in the corporate directory (depending on how
the customer has implemented Trim) they are effectively invisible to consumers
without something equivalent to a ‘getGroups’ service. For
example if there is a Trim Group called ‘All Melbourne Users’ how
will a consumer ever know this exists and thus how can they ever set the ACLs
for this group? The impression I got from previous
discussions was that few (if any) other repository vendors had this problem, so
I am interested to see that at least one other person who feels this pain. Anyone else out there? If we have one or
two more maybe there will be enough momentum to justify a JIRA issue? Thanks, David From:
Bram de Kruijff [mailto:Bram.deKruijff@gxsoftware.com] Hi David and list, Not sure if I get the question entirely,
but yes our product (GX WebManager) has an internal directory as well. Mostly
to support deployment models without any corporate directory in sight, but we
can also add native groups on top of external principals. Guess that’s
kind of your use-case? So, do you want the client to able to
query for groups (through CMIS) in general or just get access to his own groups
for the current principle? Just wondering about three possible directions. Expose your groups through standard CMIS
/trim/groups/* as child of cmis:document. Makes it queryable and, if I
understood the discussions correctly, you can do it without a
content-stream. I guess this feels kind of awkward, probably requires some
permission juggling and it is within the spec, but not in the spec. If I remember correctly TRIM also has
some challenges with mapping to the file/folder model? Same here :) I think Jay
suggested opening things up by exposing super type cmis:object through allowing
much more flexibility in modeling a custom domain. This would possibly
allow you to model approach 1 in a less awkward way (eg by being able to
introduce a trim:group extending from cmis:object)? In general I am curious as
to what people think about this idea! Then again, this still would leave the
repository idea outside the spec. Adding an optional directory capability
service of some sort making it part of the spec. It would address the TRIM
challenge(?), but I guess also a deployment model where the client does not
have (enough) access to the directory (eg. from public web) to get the required
intel directly. A repository could then proxy it. Does anyone think that is a
real use case? So, just some thoughts. Would be happy
to hear some pros and cons to these ideas as it will help me as well in
sharpening my understanding of CMIS. Best Regards, Bram de Kruijff Ps. Noticed the list does not properly
set the reply-to address to the list. Known issue or can we do something about
that? -- GX | Bram de
Kruijff | Product Architect | Wijchenseweg 111 | 6538 From:
Churchland, David [mailto:david.churchland@hp.com] I am curious to see whether our repository (HP Trim) is the only one
with the following CMIS mismatch. The only information CMIS presents for a user is the principal ID,
under the assumption that all users (and groups) are in the corporate
directory. This is fine for people but HP Trim uses groups extensively.
These groups are not from the corporate directory but exist only in HP Trim’s
internal directory. While for a user we can use their login name as their principal ID I
cannot determine how we could usefully identify a group as the internal HP Trim
ID is meaningless without access to Trim, and the group’s name is not a
unique identifier. Plus we have no service to get a list of these groups. So, for example, if we supported groups a CMIS user wanting to apply an
ACL to a Trim group would have to know that ‘Trim_Group_56435’ is
the group they want. Does anyone else have this model where the repository user directory is
a superset of the corporate directory? In particular where there are
groups in the repository directory that do not exist outside the repository. If yes have I missed an obvious solution to my problem? If no I will just have to live with it I suppose. Thanks, David Churchland HP |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]