Re: [higgins-dev] Another STS Request

[Michael McIntosh <mikemci@xxxxxxxxxx>]

Daniel, et.al.

Generally, I have tried to provide reasonably structured elements where 
the schema specifies structure.
In the example below (wst:Claims) you are asking for a framework 
optimization based on the "CardSpace Profile" of WS-Trust.
WS-Trust does not specify the format of the wst:Claims element; doing 
anything useful with the content of a Claims element requires knowledge of 
the "dialect". I prefer not to embed that knowledge at the core framework 
level. 

/wst:RequestSecurityToken/wst:Claims 
This optional element requests a specific set of claims. In most cases, 
this element contains claims identified as required in a service's policy. 
Refer to [WS-Policy] for examples of how a service uses policy to specify 
claim requirements. The @Dialect attribute specifies a URI to indicate the 
syntax of the claims. No URIs are predefined; refer to profiles and other 
specifications to define these URIs. 

<xs:element name="Claims" type="wst:ClaimsType" />
   <xs:complexType name="ClaimsType">
      <xs:sequence>
         <xs:any namespace="##any" processContents="lax" minOccurs="0" 
maxOccurs="unbounded" />
      </xs:sequence>
   <xs:attribute name="Dialect" type="xs:anyURI" use="optional" />
   <xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>

Michael McIntosh
Java and Web Services Security Group
Security, Privacy, and Extensible Technologies Department
IBM Research

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/27/2007 03:07:16 PM:

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=175739
> 
> >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 2/27/2007 10:18 AM >>>
> So we should make sure these are put into bugzilla and then tracked 
> on a milestone
> -----------------
> Sent from my BlackBerry Handheld.
> 
>  ----- Original Message -----
>   From: "Daniel Sanders" [dsanders@xxxxxxxxxx]
>   Sent: 02/27/2007 09:25 AM
>   To: <higgins-dev@xxxxxxxxxxx>
>   Subject: [higgins-dev] Another STS Request
> 
> Mike,
> 
> In discussions yesterday with a developer here at Novell who is 
> using the STS, he made another request for some changes that I 
> thought were reasonable.  I thought I would put the request to the 
> dev-list so that it would be documented.  This is one that, if you 
> feel ok about, I would be happy to work on and submit a change (when
> I get some time).
> 
> The request is this:
> 
> He proposes that the IRequestSecurityToken interface be modified so 
> that instead of passing DOM nodes to/from the various setter/getter 
> methods, we pass higher level types - so that we don't have to set 
> up XML DOM nodes to use the interface.  He would like to use the 
> RequestSecurityToken class (which implements the interface) 
> independent of XML.  He recognizes that much of the time an RST 
> message will come into the STS as XML, and so it is very important 
> to have code that parses the XML and creates a RequestSecurityToken 
> object.  However, he suggests that it be helper code, not 
> intricately woven into the RequestSecurityToken class or the 
> IRequestSecurityToken interface.  He has a case where his RST 
> message will be generated by policy as opposed to an explicit XML 
> message.  Yes, he could generate an XML message, but it would be 
> much more convenient if he could simply instantiate the 
> RequestSecurityToken object directly and populate it in a more 
> "natural" way than by having to create XML DOM nodes.
> 
> So he proposes that all of the code which parses an XML RST be made 
> helper code that creates the "right" kinds of types to be passed 
> into the RequestSecurityToken object.  For example:
> 
> setClaims/getClaims - passes/returns an IElement, which is then 
> parsed into an array of claims (java.util.ArrayList) later in the 
> IssueHandler.java code.  This would be more convenient if the 
> ArrayList object could be passed instead of the XML IElement node, 
> and move the parsing code currently in IssueHandler.java to the 
> BindingHelper.java code.
> 
> Other setters/getters could be similarly changed.
> 
> Any thoughts? suggestions?
> 
> Thank you,
> 
> Daniel
> 
>  _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev