Re: [higgins-dev] Changes to STS

[Michael McIntosh <mikemci@xxxxxxxxxx>]

higgins-dev-bounces@xxxxxxxxxxx wrote on 03/26/2007 12:32:33 PM:

> Mike,
> 
> Thank you for this list.  This is great.
> 
> Last week I also ran into another issue as we were preparing for our
> Brainshare demo.  My code is a couple of weeks old (I needed to keep
> it stable for Brainshare), so perhaps you have already addressed 
> this issue....  The issue has to do with how the STS generates 
> display names.  In my snapshot of the STS code the display names 
> were all hardcoded based on the claim types.  Because we had a 
> couple of new claim types we wanted to use in our demo, I had to 
> modify the code to add those types.  I know there has been 
> discussion in the past about getting these display names from 
> attribute meta-data from the context provider.... Is that still the 
> plan?  For a context provider to generate a display name it will 
> either have to hardcode the names itself, store them in schema, or 
> use a mapping provider that makes them easy to dynamically configure
> for a particular deployment.  Hardcoding in the provider is really 
> not much better than hardcoding in the STS.  I don't like the idea 
> of storing display names as meta-data on the schema, because it is 
> not flexible enough in my opinion - the point in time at which the 
> display name is decided is disconnected from any specific use case 
> or deployment scenario.  Given that, I prefer using a mapping 
> provider.  I think that Duane's new IdAS JS mapping provider could 
> be used... If we use a mapping provider, I think there could be a 
> case for just having the STS do it - no need for attribute meta-data
> from the context provider. ... Anyway, something we need to resolve 
> fairly soon...

Yes, I agree. Let's see how it looks when the mapping provider is 
implemented and a description of how to use it is provided.

> Just so you'll know, I was planning on doing a post-Brainshare 
> redeployment of the STS on our Wag site - trying to integrate the 
> most current STS using the latest JNDI provider - one where 
> attribute name mappings are not hardcoded anymore (this is different
> from the display name mappings mentioned above).  As far as you 
> know, is the STS that is currently checked in stable?  I was 
> thinking I could take a snapshot of that before you start checking 
> in the changes you listed below - if you feel it is stable enough.

Yes it is pretty stable. I tried to make sure what was there would suffice 
for a few days while I made these changes.

> I think using branches in CVS is a good idea.  I also think it would
> be very useful to begin regularly posting the latest "stable" 
> downloads - a tar/zip file with source and a list of dependencies.

I keep hoping to hear that nightly builds are working but so far nothing 
has happened in that area.

> 
> Thanks,
> 
> Daniel
> 
> 
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 3/24/2007 11:38 AM >>>
> 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.
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev