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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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]