[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Differentiating between Application and Security roles
Rich Thompson wrote: > > Since there is no normative content, I would favor this type of > discussion in the Security Tech Note rather than the spec, though it > would need to take a more neutral stance (I think this casts too > negative of a view onto the security mechanisms and too positive on the > "weak authentication" mechanism). > > What I had tentatively added to section 9.3 from the discussion on the > last Interfaces SC call was > "It should be noted that the security concept of access control is > generally controlled by subsystems/protocols operating at a lower layer > than the WSRP implementation/protocol and that this should not be > confused with the application level concept of user categories, despite > an apparent overlap in utility." Do we have to keep the last part of this sentence (from "despite an apparent ...")? Subbu > > If we do add an expanded discussion of this flavor to the Security Tech > Note, it would also be appropriate to add a reference to it. > > Rich > > > *Michael Freedman <michael.freedman@oracle.com>* > > 07/12/05 07:02 PM > > > To > wsrp <wsrp@lists.oasis-open.org> > cc > > Subject > [wsrp] Differentiating between Application and Security roles > > > > > > > > > We are discussing how to rework section 9 [Security] so that it isn't as > vague as it currently is. One area I have proposed improving is > providing better clarification concerning security and UserContext; in > particular user categories and security roles. Here is an initial > description to get discussion started -- it will need work but I am sure > there is enough here to get the sparks flying: > > *Identity Propagation and Authorizations:* > Typically, user identity and authorization is managed for the > application by the underlying security system in the application's > operating environment. In many circumstances this will also be true for > Producers. However its important to recognize that because the producer > is a consumed resource an alternative whereby the consumer can present > this information to the producer in a non-secure though potentially > trusted manner exists. Distinguishing between these various options is > important to implementing correct producer function especially where > security is paramount. > > An operating environment's security system is responsible for > establishing the [authenticated] identity of the user and presenting > this information along with this user's authority to the running > application. Depending on the complexity of the operating environment, > such a security system may need to rely on a whole range of mechanisms > to ensure the application can maintain a secure conversation with an > authenticated individual. However because this behavior is rooted in > the operating environment prior to the execution of any application > layer code, applications can be ensured that the information presented > to them is valid and trustworthy. Web server environments have defined > and handled this well when there is direct communciation between the end > user and the resource. But what about when there is indirect > communication such as is the case with a WSRP producer which is > controlled by an intermediate consumer? In this situation the consumer > and producer environments must cooperate to propagate the information. > The WSS standards and associated profiles define a wide range of > techniques that allows a consumer of a web service to propagate the user > identity and permissions to the web service's security system to allow > this operating environment to operate the service in a secure > environment. WSRP relies on these standards/layers for implementing > security. > > The only drawback to this solution is that this requires the consumer > and producer environments to support the same portions/levels of the WSS > standard and that each is manually configured so they can work together. > Though somewhat of a burden its certainly reasonable for any producer > that wants to ensure its securely operating on behalf of the user. For > example, a portlet that deletes employees from an HR database wants to > be sure that it only allows properly and securely identified users with > the required permissions to do so. > > However, there are many producer situations where strict security isn't > always necessary but receiving a notion of the user's identity and > capabilities is. Examples include using the user's identity to > construct a shared key to coordinate data sharing between portlet's in > the producer, restricting the modes any user has access to based on the > user's capabilities or likewise altering the view of any given mode > based again on the user's capabilities. For these situations, WSRP > provides a lightweight form of consumer propagation that is managed at > the application level and hence from a strict security view point is > insecure. This is the purpose of the UserContext. The WSRP user > context tells the producer 3 things: > 1. Whether the consuming application has identified the current > user. > 2. If the consumer has identified the current user, then the > producer is given a key value that uniquely represents that user. > 3. What WSRP user categories pertain to the user of this request. > [WSRP user categories are producer declared values that the consumer is > responsible to mapping to somethign appropriate in its environment. > Typically, when done so by the consumer, these user categories will > reflect a mapping between the consumers notion of application roles [not > necessarily security roles] and the producer's categories. ] > Though commonly some kind of trust relationship exists between the > consumer and producer, its important to note, that the producer has no > notion of how the consumer derived this information and hence it can't > be considered secure from a security system standpoint. For example > there is no requirement that the consumer has authorized the user > [securely] before it identifies the user to the producer. For example > the consumer may support weak authentication in addition to strong > authentication. I.e. we are all familiar with web sites that use a > cookie to store the identity of a user for longer then an immediate > session so the site can rertain a personalized view. However once the > the user tries to access a function that requires full authentication, > he is challenged. Likewise, there are no requirements for how a > consumer will map producer user categories. Again, its perfectly valid > for a consumer to randomly generate the values or even merely say that > all users are in all categories. > > The key benefit of this mechanism is it requires no cumbersome out of > band setup in both the consumer and the producer. Nor does it rely on > the consuming/producing operating environments supporting a consistent > portion of the WSS stack. > > So what are the guidelines for using one mechanism over the other? > > Consider using WSRP UserContext in those situations where weak > authentication is acceptable. Again, weak authentication is defined as > the presentation of identity/capabilities without its having been > securely authenticated. Examples include restricting access to > descriptions or operations of portlets, adjusting the > available/supported modes, and altering the type of content presented. > These aren't hard and fast examples as there are many situations in > which a portlet wants to control these functions securely. That's why > the critical question to ask is can/should/ my function be controlled by > weak authentication or not. > --------------------------------------------------------------------- To > unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > --------------------------------------------------------------------- To > unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]