[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] Roles
Hello WSRP fellows. I wish everybody a happy new year 2003! In preparation of tomorrow's first WSRP call in 2003 here comes a summary of my point of view regarding roles in WSRP: Proposal: Leave every aspect related to roles out of the WSRP specification (and rely on other standards instead, see below) Currently in the spec: The Producer MAY advertize the roles it supports on a per entity basis. These roles are non-localized strings. During a call to one of the methods of the markup port-type the Consumer MAY pass a set of roles. The Producer MAY trust this set of roles (e.g. because it has established a trust relationship during registration) and may behave differently based on the consumer's role assignment. It is important to note that the Producer has no means to verify these role assignments but it must trust the Consumer. Why I think we should leave roles out: 1. The notion of roles has clearly a relation to security aspects because the Producer could choose to use the role assignments to show/hide security relevant information when generating markup (e.g. give more information to admin roles). We already decided for all other security relevant parts to rely on other existing or forthcoming standards (SSL, WS-Security) because this greatly faciliates interoparability. We should do the same with roles and wait until this problem is addressed by the WS-Security committee. 2. The idea that the consumer asserts a set of roles and the producer trusts this assertion without checking again contradicts common WS security paradigms. Both JSR109 (integration of WS in a J2EE environment) and the WS-Security approach are different. They rather define how credentials flow with a web services call. It is then the task of the Producer to validate these credentials and assign roles based on these credentials. No further trust relationship is required. I admit that the standard are silent on how a probably necessary user mapping should take place, but this will be addressed in the upcoming WS-federation spec. 3. Specific to a producer implementation on J2EE I furthermore see the following problem in a JSR168 mapping: JSR168 does not define any role concept but refers to J2EE roles. e.g. it assumes that isUserInRole works from both a portlet and a possibly included servlet. There is no way to explicitly access WSRP roles (although this could be done in a proprietary way). Hence a J2EE implementation would need to make sure that WSRP roles become J2EE roles. This however poses a problem. Normally it is the application server that asserts roles and satisfies the isUserInRole call based on credentials. In the WSRP case there are no credentials, the app server is supposed to trust unsecured role information. As the isUserInRole call cannot simply be overridden as it needs to work from EJBs and servlets also, the app server core must be hacked to make role assignments without credentials possible. This seems to be a very odd approach and makes the standard impossible to implement for non-app server vendors. It also compromizes the security policy of an app server. 4. What should happen if the consumer passes user credentials (e.g. in conformance with JSR109) and in addition WSRP roles? The Producer's app server would automatically assign the roles that correspond to the credentials. What now if they conflict with the WSRP roles? For me the arguments above point strongly in the direction of leaving roles out. What could be done instead to achieve a similary behaviour is the following: The Producer defines users that correspond to all possible (rather all sensible) permutations of roles and advertizes these users' credentials instead of the roles. The consumer then makes the WS call in behalf of one of these users (very much like it works for EJBs now). The consumer makes use of standard techniques to pass these credentials (e.g. basic auth or WS-security). The producer can validate the credentials as they correspond to a real user in its user subsystem and assign the corresponding (J2EE) -roles automatically. The user profile key (as it is currently in the spec) still exists and makes user awareness possible. The advantage of this approach is that it completely relies on standard techniques and works out of the box. The drawback is that you would need one specific user for all role permutations. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC