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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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


Subject: RE: [wsrp-wsia] Roles


ProducerRoles and userContextIds are for Portlets only. As such they are
very useful, but a Portlet can always request a user login (via markup UI)
for access to back end systems (that require a real identity in the producer
domain). So we need not mandate WS-Security.

	-- Andre

-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: 27 November 2002 09:16
To: Alejandro Abdelnur
Cc: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Roles


Alejandro -

I share Rich's concern regarding roles for the reasons your are discussing
on, but also for a principal reason:
in WSRP we define how roles flow (optionally) but rely on WS security
standards (e.g WS-security) to define how identity flows (i.e.
username/credentials). I am not talkting about the user profile key which
is only used as key in the database but about real identity.
In a J2EE world I would assume that the roles that flow via WSRP would be
the roles a programmer can access via the J2EE isUserInRole call,
especially for the case of JSR168. There might be a mapping in between but
in principal the WSRP role information should be present as a J2EE role.
This poses a practical and a conceptual problem:
1. the practical problem: without any credential flow that would accompany
the role flow, how is the producer's app server supposed to satisfy the
isUserInRole call? We cannot simply override this method as it needs to
work not only in the context of a portlet but also in the context of all
J2EE calls the portlet could make (e.g. the portlet calls a JSP or a EBJ)
2. the conceptual problem: even if we manage to satisfy the isUserInRole
call (by hacking the app server) the concept is not in line with the
WS-security and JSR109 approach. Their concept is that they define how user
credentials flow with each WS call and that the producer then MUST validate
these credentials prior to satisfying the call. So there is no hidden trust
or implied credentials. With our roles however we would need to imply such
information as only the role's name flow and we expect the producer's app
server to trust the consumer and grant access to its secured resources
based on role information without a password flowing. In addition what
happens the the consumer decides to leverage WS-security to pass
username/credentials to the producer (as we suggest). In that case the
access point on the producer automatically interprets the credentials from
the WS-security header and establishes the J2EE security context (login +
role assignment). So the call already has associated J2EE roles. What
happens if the explicit WSRP roles conflict?

As a summary I see the WSRP role concept (event though optional) as broken.

We should completely discard it and rely on WS-Security instead.

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



                                                                           
             Alejandro                                                     
             Abdelnur                                                      
             <alejandro.abdeln                                          To 
             ur@sun.com>                                                   
                                                                        cc 
             11/27/2002 12:13          wsrp-wsia@lists.oasis-open.org      
             AM                                                    Subject 
                                       Re: [wsrp-wsia] Roles               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





I agree with Mike.

Yet another option would be:

   d) Consumer arbitrary mapping: The consumer would associate many
producer roles to a single consumer role. For example, the consumer
would map both producer.seller and producer.buyer to consumer.user. All
users with consumer.user role would have the producer.seller and
producer.buyer roles.

Alejandro

Michael Freedman wrote:
> Rich can you explain why you reach your conclusion that this smells like
an extension?  It
> doesn't to me.  Though I agree there will be problematic mappings, the
mechanism we have
> defined is useful [when it can be used] and properly needs to be
standardized for these
> situations.  By leaning towards making this an extension you seem to
imply that the
> consumer and producer will have to come together to make this work anyway
which is exactly
> our expectation for all extensions.  I see a different outcome.  To me,
administrators of
> consumers get a choice when presented with foreign roles that no existing
consumer role
> maps directly to -- the administrator may create new roles in the
consumer [if possible] to
> match the producers requirements or the administrator may choose to abort
the registration
> and not interact with the producer.  I.e. for your example I see one of 3
outcomes:
>      a) The existing roles map:  I.e. it might be that this consumer only
wants to interact
> with the buying function and is happy to map all its users to the
producers "Buyers" role.
>      b) Create new roles:  I.e. when no good mapping exists the consumer
[if capable] can
> create new roles corresponding to the producer functional roles.  In this
case the consumer
> creates a new "Buyers" and "Sellers" role.
>      c) Drop the producer:  If no good mapping exists to necessary
function and new
> consumer roles aren't added then the administrator makes a decision to
not use the
> producer.
>
> Since in both case (a) and (b) above the consumer uses the producer and
supports role
> mapping it must pass the role information in its requests.  Wouldn't we
want this
> standardized so the producer receives/interacts with roles in a standard
way?
>     -Mike-
>
> Rich Thompson wrote:
>
>
>>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>
>
>
>
> ----------------------------------------------------------------
> 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