| Re: [higgins-dev] Changes to STS |
|
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...
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.
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.
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 |