[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#175] Roles should be per-Entity and not per-Producer
Carsten, What you describe is more of an extra, orthogonal authentication and access control security mechanism. One that: 1) allows the consumer to sign in to a producer (establishing a trust relationship). 2) allows the producer to police the consumer (so as to conform to a role based security policy). 3) [possibly] allows the consumer to run under impersonation (e.g. consumer as user==retailer1). This seems a valid vendor extension and I'm sure there will be others like it. For 1.0, I would rather standardize a "username/password" registration property than add WS-Security credentials, but that is another matter. Your proposal, as I understand it, does not, however: a) communicate the set of roles that are allowed for any one consumer into which the consumer can place its local users. b) communicate the (current) set of roles held by the user a markup request is invoked for. We have roleDescriptions in serviceDescription and producerRoles in EntityDescription for (a) and producerRoles in UserContext for (b). The standard mechanism (WS-Security) can wrap up the application specific one (WSRP) [onion layers of security with remote Portlet at core], as I believe both consumer authentication and access control and portal user role management are real requirements. I think the fundamental issue comes from trying to leverage the JSR 168 / J2EE API for both, when, in fact, it is more like having both OS and Application Server (or Java) security layers. My preference would be to use the (non standard) consumer authentication & access control mechanism (WS-Security as you propose) as the one reported by the Servlet-like Java APIs [Note, an unauthenticated consumer would have no rights propagated to the back ends] and to use a *new* role API for WSRP Portlets so that they can manage fine grained (i.e. users in consumers) remote (i.e. subsets specified by consumer) Portal roles. Then J2EE security works as for Web applications and remote Portlets can add additional security logic and role based customisation for remote users. regards, Andre PS. Similar application end-to-end arguments apply for standardized use of edit mode but I won't go there again. -----Original Message----- From: Carsten Leue [mailto:CLEUE@de.ibm.com] Sent: 10 December 2002 17:43 To: Andre Kramer Cc: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#175] Roles should be per-Entity and not per-Pr oducer Hi Andre. I think that the general approach to pass the roles in the context of a trust relationship is already questionable. Normally - from my knowledge - it rather works the way that a server (our producer) verifies the user credentials on his own and assigns roles accordingly. The solution for WSRP would be as follows. 1. we do not pass roles at all 2. we use WS-Security to pass user credentials (optionally). WS-Security support is built-in in standard java stacks and the .NET stack. The credentials and the respective server side role assignments will be handled automatically by the stack. The question now is what user credentials to pass. I see two options: - during registration the producer tells the consumer a pair of credentials. In this case the consumer portal would be seen as a user that logs in to the producer portal with each WS request. The producer could then assign roles to this consumer-user in the "normal" app server specific way. The end-user would still be keyed via the user identifier we pass as part of the user profile (however the user would not be logged in) - if producer and consumer share the same user population the real end-user credentials could be exchanged. The information if the population would be shared would be part of the registration process also. Does that make sense? My strong feeling is that if we use roles we establish a parallel authentication concept to WS-security that will become obsolete and hurt us a lot in the future. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 Andre Kramer <andre.kramer@eu. citrix.com> To Carsten Leue/Germany/IBM@IBMDE, 12/10/2002 05:34 wsrp-wsia@lists.oasis-open.org PM cc Subject RE: [wsrp-wsia] [I#175] Roles should be per-Entity and not per-Pr oducer I must confess I am not able to keep up with the latest and greatest security specs developments, but is WS-Security not more a framework for developing security protocols rather than a protocol we could use as is? Could you describe how WS-Security (SAML seems a better framework for this) could be used to agree on the set of role definitions to be shared by the producer and consumer and how it would be used to pass roles information along with the rest of the UserContext we now have? I could then check if I'm able to do this using the .NET tool chain, for example. regards, Andre -----Original Message----- From: Carsten Leue [mailto:CLEUE@de.ibm.com] Sent: 10 December 2002 16:03 To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] [I#175] Roles should be per-Entity and not per-Producer Just to reopen the role discussion: instead of thinking of refining the role support we should think of dropping it altogether. I summarized the reasons for this already in another email. One example reoccurs in Eilon's example - the producer that spans multiple web-apps in J2EE. For me this seems to apply that the producer would use the app's J2EE roles as WSRP roles. In this case I would also assume that after a WSRP call containing such role information a call like isUserInRole would work on the producer. However as no credentials are sent around this is impossible to implement. From my point of view it would be best to rely on WS-Security. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 Gil Tayar <Gil.Tayar@webcol lage.com> To wsrp-wsia@lists.oasis-open.org 12/10/2002 09:18 cc AM Subject [wsrp-wsia] [I#175] Roles should be per-Entity and not per-Producer Issue: 175 Status: Active Topic: interface Class: Technical Raised by: Eilon Reshef Title: Roles should be per-Entity and not per-Producer Date Added: 10-Dec-2002 Document Section: v0.85/4.1.7 Description: RoleDescription[] - should it be per each Entity and not per Producer? The current model only supports roles per Producer which works when the Producer is a centralized portal environment, but makes it much harder to manage and deploy changes in less controlled environment. For example, this means that if a development environment allows portlet developers to define custom roles per portlet (e.g., if one Producer may span multiple web-apps in J2EE), then the Producer must continuously accumulate all roles from all its portlets to present a coherent role list. And, the Consumer needs to sample that list more often to ensure that there are no changes. Another example is how would an application-level-WSRP-proxy support multiple services with different roles? ---------------------------------------------------------------- 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