[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Roles
I presume the consumer side B2E relationship manager can choose not to map
some of the roles or map them 1 to N, all on a person by person basis?
producer-Admin <-- herself as consumer-User
producer-Buyer <-- No one at this consumer (as we only make Software)
producer-Seller <-- Fred in Sales as consumer-Administrator (Salespeople are
god-like after all :-)
I believe that this is a common business problem that we must support
(provide mechanism not policy). The trust relationship established at
registration time (and by modifyRegistration()) will provide a security
scope (which we could add as a new scope to our spec if we think the spec is
lacking) for the above relationship.
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 26 November 2002 21:25
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Roles
What was missing from the email you responded to was the original issue
comments ... copied here for reference. Please explain how the
administrator maps roles in this case:
In pulling this together I have worked through clarifying a number of areas
people questioned, including sections 8.3 & 8.4 discussing interoperability
of roles. It currently discusses how Producers and Consumers making
different choices about supporting this option. The one area this has left
me with big concerns is when both choose to support roles. I don't see any
clearly definable semantics whereby Consumer maps its roles to the Producer
published roles. To keep it simple, I would like to consider the scenario
where:
The Consumer only supports the spec defined roles of Administrator, User
and Guest
The Producer declares the roles Admin, Buyer and Seller
A reasonable administrator at the Consumer will probably map the
Administrator role to the Producer's Admin role, but clearly the
granularity of the Producer's roles does not match the granularity of the
Consumer's roles. There is no reasonable mapping available to be made.
Reflecting on this further, the whole schema of role mapping only really
works when there is a huge overlap in the roles supported at the Producer
and the Consumer. To me this is more and more smelling like something that
belongs as an extension rather than an inherent part of the spec.
Alejandro
Abdelnur To:
<alejandro.abdeln cc:
wsrp-wsia@lists.oasis-open.org
ur@sun.com> Subject: Re: [wsrp-wsia]
Roles
11/26/2002 03:46
PM
How roles are mapped is clear (an admin does the mapping), what is not
clear is the idea of automatic mapping (without admin intervention).
IMO, not having a solution for this automatic mapping is not an argument
for dropping all concept of roles from the spec.
Alejandro
Rich Thompson wrote:
>
>
>
>
> What I am saying is that we either need to clearly define the semantics
> (including how roles can be mapped when there is no match in the
> granularity of role definitions) or drop all concept of roles from the
> spec. Note that the later case does not eliminate using roles when both
> sides agree on how to do this (e.g. JSR109), but rather leaves this area
to
> other specifications the end-points also choose to support.
>
>
>
>
> Alejandro
> Abdelnur To:
> <alejandro.abdeln cc:
wsrp-wsia@lists.oasis-open.org
> ur@sun.com> Subject: Re: [wsrp-wsia]
Roles
>
> 11/26/2002 12:54
> PM
>
>
>
>
>
> Rich,
>
> Are you suggesting to drop the predefined roles from the spec?
>
> Alejandro
>
> Rich Thompson wrote:
>
>
>
>
> This mapping works reasonably in a J2EE environment because the
> granularity
> of role definitions doesn't vary too dramatically. As a web service
> spec,
> WSRP had better worry about cross platform issues as well. As soon
as
> one
> moves out of the J2EE world, the chances that the granularity of
role
> definitions is close drops precipitously.
>
> Rex suggested the role fields could just be optional ... they are,
> but what
> this means for a Consumer that doesn't use roles and wants to use
the
> maximum number of Producers is pretending they support the spec
> defined
> roles (e.g. mapping whatever internal access control mechanisms are
> in use
> to the spec defined roles) and trying to map these onto the
Producer
> published roles. I assert this will fail miserably more than it
will
> succeed.
>
>
>
>
> Andre Kramer
>
> <andre.kramer@eu. To:
> wsrp-wsia@lists.oasis-open.org
> citrix.com> cc:
>
> Subject: RE:
> [wsrp-wsia] Roles
> 11/26/2002 08:48
>
> AM
>
>
>
>
>
>
> J2EE also has the concept of role mapping in that a developer can
> write her
> application in terms of her usual set of roles. The deployer of the
> application can then map those roles, at deployment time, using a
> relatively
> simple XML role reference description mechanism. I view wsrp
consumer
> roles
> as the analogue of the J2EE developer's role set, the consumer
Portal
> admin
> as the analogue of the application deployer (at service
registration
> time),
> and the role names on the wire as the J2EE container roles. So, we
> potentially have two similar mappings of roles: consumer to
producer
> and
> JSR
> 168 Portlet to J2EE Container? Each requiring human intervention.
>
> regards,
> Andre
>
> -----Original Message-----
> From: Rich Thompson [mailto:richt2@us.ibm.com]
> Sent: 26 November 2002 12:52
> To: Martin Bryan
> Cc: wsrp-wsia@lists.oasis-open.org
> Subject: Re: [wsrp-wsia] Roles
>
>
>
>
>
>
>
> I have had the uneasy feeling about roles for a while, but
rewriting
> those
> sections finally caused me to focus on it enough to see the
detailed
> reasons why (you site some good examples). At this point I think it
> is only
> useful to that set of Consumer-Producer pairs that have a
coordinated
> set
> of roles and since we won't be able to define tight semantics it
> doesn't
> belong in the spec.
>
> On the address side, the variations in address are a big issue and
> WSRP is
> not the right place to tackle it. We took guidance from the P3P
data
> model
> in this area though we did need to provide some structure for their
> unstructured portions. I was hoping much of the variability could
go
> into
> the field named street as this is an array of strings. In addition,
> each of
> the structures is individually extensible with the expectation that
> some of
> those extensions will come back for consideration as base level
> fields in
> v2. If there are other sources that would give a more
> internationalized
> view of this area, we certainly would appreciate a pointer ....
>
>
>
>
>
> "Martin Bryan"
>
> <mtbryan@sgml.u-n To: Rich
> Thompson/Watson/IBM@IBMUS
> et.com> cc:
>
> Subject: Re:
> [wsrp][wsia]
> Draft spec v0.85
> 11/25/2002 11:35
>
> AM
>
>
>
>
>
>
>
>
>
> Rich
>
>
> Reflecting on this further, the whole schema of role mapping
> only really
> works when there is a huge overlap in the roles supported at
> the Producer
> and the Consumer. To me this is more and more smelling like
> something
>
> that
>
> belongs as an extension rather than an inherent part of the
> spec.
>
>
> At last you are beginning to see the problem. Now consider what
> happens if
> the Producer is Finnish and the Consumer is Japanese and both use
> their own
> languages to define their services. Now we have a real problem,
which
> will
> only be solved if you introduce a multilingual ontology of mapped
> terms
> into
> the equation.
>
> The real problem, however, is how to do this dynamically, so that
we
> can
> annotate recorded roles with "related names from other sources"
(e.g.
> record
> that someone has determined, by some off-line means, that A relates
> to B).
>
> Incidentally your address info structure in section 10 has not been
> suitably
> internationalized. You need techniques for defining subsections of
> what you
> call cities (e.g. Kensington, London) and for identifying blocks
> (both at
> street and house level) and subunits of buildings (flats or
suites).
> For
> example, I have a friend in Roumania for whose address I need to
> identify
> the flat number, the staircase, the block on the road (unless you
> call
> Block
> 26 a name!) and the district of the town in addition to the fields
> you
> allow
> me to define once only if I want to send him something. It looks
like
> I'm
> going to have to define more extensions than you do base fields,
even
> though
> every different Consume and Producer will have to define his own
set
> of
> extensions for most of these :-(
>
> Martin Bryan
> The SGML Centre, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
> Phone/Fax: +44 1452 714029 E-mail: mtbryan@sgml.u-net.com
>
> For further details about The SGML Centre visit
> http://www.sgml.u-net.com
>
>
>
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC