[higgins-dev] Re: STS Question About ISecurityInformation interface

[Michael McIntosh <mikemci@xxxxxxxxxx>]

"Daniel Sanders" <dsanders@xxxxxxxxxx> wrote on 11/30/2007 12:45:26 PM:

> Mike,
>
> We have a question concerning the way security information is passed
> through the STS down to the TokenHandler objects.
>
> We need to handle the following kinds of credentials/security tokens:
>  1) Username - Password
>  2) PPID + Public Key
>  3) User defined custom tokens
>
> The current Higgins code explicitly supports 1 and 2.  It appears to
> us that the STS also intends to support 3 through the following methods:
>
> package org.eclipse.higgins.sts.api;
>
> public interface ISecurityInformation
> {
> ....
>    public abstract java.util.List getSecurityTokenList();
>
>    public abstract void addSecurityToken(IElement elemToken);
> }
>
> We want to verify with you that this is your intent.  Any credential
> type not recognized could be placed in this list and passed to
> handlers for processing.  The STS does not currently do this, but it
> seems that it could/should.

Yes, that is the intent. I started implementing this a while ago, but never
finished.

>
> We were also wondering about whether the ISecurityInformation
> couldn't be entirely replaced with a simple Map object.  Instead of
> having specific methods for getUsernameToken, setUsernameToken,
> getModulus, setModulus, etc. we could simply use the Map object's
> set/get methods and define specific key strings for things like
> username, modulus, etc.  It would also be very useful if the map had
> a way to set/get the "kind of" credential.  Something like this
> might make it easier to implement custom credential types.
>
> This would also make it easier to extend when you get around to
> handling Kerberos and X509 credentials.
>
> What do you think?

In theory I agree. However, in another part of the theoretical space it is
possible for a single WSS Header to contain more than one of any Security
Token type, and in some parts of this theoretical world the order of these
Security Tokens in the Security Header matters (first one is proxy, second
user/originator, etc.).

I think the ISecurityInformation needs to maintain an ordered list. I'd
like to be able to represent each of these picees of security information
(ISecurityPart?) via a single interface from which are derived things
(ISecurityPart into ISecurityToken, ISignature, IEncryptedData,
IEncryptedKey, ITimestamp, ISecurityTokenReference, etc.). Each of these
could be derived further (e.g. ISecurityToken into IUsernameToken,
ISAML11Token, ISAML20Token, IBinarySecurityToken, etc. then
IBinarySecurityToken into IX509Token, IKerberosToken, etc.). Any
ISecurityPart could be checked via "if (securityPart instanceOf
ITimestamp) ...".

I think the ISecurityInformation should contain an additional method to
provide almost what you ask for:
      public interface ISecurityInformation
      {
            ....
            public abstract java.util.List<ISecurityPart>
getSecurityPartList(); // Java 5 syntax used for clarity
            public abstract java.util.List<ISecurityPart>
getSecurityPartList(Class partType); // Returns an ordered list of
instances of the class/interface.
            public abstract void addSecurityPart(ISecurityPart part);
      }

>
> Thank you,
>
> Daniel Sanders
> Stuart Jensen
>
>