[higgins-dev] Changes to STS

[Michael McIntosh <mikemci@xxxxxxxxxx>]

This note serves as a high level notification of several STS related 
architectural changes that I intend to check in over the course of the 
next week or so. Some of these changes have been discussed before, but not 
completed due to demo commitments. These changes are somewhat 
interdependent, epsecially the configuration changes. It will take a few 
days for them to be completed.

Since I don't want to have significant uncommitted changes stored only on 
my laptop - I'm planning to check them in as they are completed. When each 
change is ready I'll send a note with more details explaining the change 
and its impact on consumers at least one day before checkin (I am starting 
to think learning to work with branches might be worth the time - maybe a 
topic for f2f).

1. Configuration redesign:

Currently there are a set of "global" settings that are visible to the 
core, and handler specific settings that are visible to each handler. The 
core code does not see into the handler settings and the handler code does 
not see any setting except its own. This has resulted in duplicate 
settings in the core and handlers that have to be kept consistent. Also 
the current <Property Name="..." Value="..."/> format is limited to simple 
unstructured settings (only what can be an attribute value.

As we discussed a long while ago (2nd f2f?), the current thinking is along 
the lines of:
        <Setting Name="..." xsi:type="...">...</Setting>
where the xsi:type indicates the format (in XML Schema terms of the 
content of the Setting element. Each unique xsi:type will map to a 
specific Java class for instance "xs:string" to java.lang.String and 
"xs:anyURI" to java.net.URI. For each xsi:type a handler will be 
registered to convert the content of the Setting element into an instance 
of the appropriate Java class:
        <SettingHandler Type="xs:string" Class="java.lang.String" 
Handler="... .StringHandler"/>.

I'll provde a schema for the Configuration and it will be parsed with 
validation turned on. Each Setting can be simple:
        <!-- The CardId to be placed into generated cards
                - see JNDI CP documentation for details
                - must point to JNDI CP config file -->
        <Setting Name="CardId" 
xsi:type="xs:anyURI">file:///C:/higgins.config.xml?id=Higgins-LDAP-Server</Setting>
or can have mixed structured content (which might include Setting 
elements) for example:
        <!--  The Key Store that contains the Issuer Certificate and 
Private Key -->
        <Setting Name="IssuerKeystore" xsi:type="xyz:keystore">
                <!-- The type of the Key Store -->
                <Setting Name="Type" xsi:type="xs:string">JKS</Setting>
                <!-- The file that contains the Key Store
                        - location relative to the Configuration directory 
-->
                <Setting Name="File" 
xsi:type="xs:string">localhost.jks</Setting>
                <!-- The password for the Key Store -->
                <Setting Name="Password" 
xsi:type="xs:string">changeit</Setting>
        </Setting>
and settings can refer to other settings:
        <!--  The Issuer Certificate -->
        <Setting Name="IssuerCertificate" xsi:type="xyz:certificate">
                <!--  The Name of the Key Store that contains the 
Certificate -->
                <Setting Name="KeystoreName" 
xsi:type="xs:string">IssuerKeystore</Setting>
                <!-- The alias for the Certificate in the Key Store -->
                <Setting Name="Alias" xsi:type="xs:string">leaf</Setting> 
        </Setting>

The result of all this will be a single high-level Configuration Map of 
Name to Object that is passed into the configure method of the core and 
each extension. The Configuration Map will also be passed into each 
handler on each invoke operation, allowing invocation specific settings.

2. DigitalIdentity: A DigitalIdentity will be added to provide access to 
values from sources other than the IdAS/Context Provider. The details of 
this are still being worked out. As I get closer to having this working 
I'll provide more details.

For now one thing that seems obvious is:

3. Token Extension Refactoring: Token Extensions need to be able to be 
split into two parts:
        a) Consumes the RST and any credentials passed in the 
wsse:Security header and generates a DigitalIdentity. 
        b) Consumes the RST and DigitalIdentity and generates a Security 
Token/RSTR.

This will make it easier to deal with the current requirement to specify 
required attributes when requesting a DigitalSubject, and will make it 
easier to reuse code.

Therefore we need:

4. Extension Container: A new configurable Extension Container that allows 
one to configure an ordered pair of Extensions. Note that I expect the 
interface to this Extension to be the same as the interface to 

5. Flexible Extension Mapping: The current method used for mapping RST to 
an Extension is very limited. It uses the 4-tuple of Issuer, Action, 
TokenType, RequestType - and if that does not give an answer polls the 
handlers via canHandle.

It is becoming increasingly obvious that this is too limited for some 
deployments. Therefore, I am planning to create a new extension point for 
a Extension Mapping Handler which can examine an RST and determine which 
Extension to invoke. One can configure a set of Extension Mapping Handlers 
which would be invoked in sequence - first one to indicate a handler 
determines which handler to invoke.

I'll implement handlers to reproduce the current behavior (one to map the 
current 4-tuple and one to poll via canHandle). Others can implement and 
configure their own mapping handlers.

6. Provide access to the raw SOAP Envelope (as IElement) via the 
STSRequest.

7. Internationalization. Literal strings for INFO, WARN, ERROR messages 
are sprinkled throughout the code, they will need to be moved to a 
ResourceBundle.

8. Audit Extension Point. Need to figure out what the best solution is for 
cross-component auditing.

9. Enhance the STS Client code to have more functionality - be easier to 
use.

10. Move Profile Web Application to writable Context Provider.