[higgins-dev] STS Architecture Question

["Daniel Sanders" <dsanders@xxxxxxxxxx>]

Mike,

We have a developer inside Novell that is using the Higgins STS.  He would like to be able to use a single common org.eclipse.higgins.sts.server.ISecurityTokenService object that can be used with his own bindings or with the Axis binding you provide.  He wants to be able to create and configure the ISecurityTokenService object himself, rather than having a singleton that is created and configured inside the SecurityTokenServiceServerBinding class.  In the case where he is handling his own bindings, he will create create ISTSRequest and ISTSResponse objects himself, and then call ISecurityTokenService.invoke().  In the case where he is leveraging the Axis bindings you provide, he wants to be able to pass the ISecurityTokenService object he created into the SecurityTokenServiceServerBinding class. -- In other words, he wants to keep track of the ISecurityTokenService singleton himself - independent of the SecurityTokenServiceServerBinding class - so that he can reuse it for his own purposes as well as for the SecurityTokenServiceServerBinding class when needed.

Right now the SecurityTokenServiceServerBinding class points to a private static instance of the ISecurityTokenService object, which is only created and configured when the SecurityTokenServiceServerBinding object is configured.  This hinders the scenario described in the previous paragraph.  To better accommodate this scenario, we would like to suggest the following changes:

1) Allow the private static SecurityTokenService member in the SecurityTokenServiceServerBinding class to be populated from a constructor or a setter method. 

2. When the SecurityTokenServiceServerBinding.configur() method is called, if the SecurityTokenService member is non-null, don't create it OR configure it -- right now if it is non-null, you won't create it, but you stlll initialize and configure it.

3) Allow the ISecurityTokenService object to be configured independent of the SecurityTokenServiceServerBinding object. -- It appears that the configure method on the SecurityTokenServiceServerBinding class is mostly doing work to configure the ISecurityTokenService object anyway.  It seems like it would be appropriate to move nearly all of that code into ISecurityTokenService class.

Are we overlooking some key thing here?  Are there reasons you have done it in this particular way that we have not taken into account? -- I guess we're just trying to get a little bit cleaner separation between the SecurityTokenServiceServerBinding class and the ISecurityTokenService class.

Thank you,

Daniel Sanders



Daniel Sanders
Software Engineer
dsanders@xxxxxxxxxx
801-861-4193

Novell, Inc.
SUSE* Linux Enterprise 10
 Your Linux is ready*
 www.novell.com/linux