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