While the first way uses a configuration file on disk, that's only one way of creating and configuring the IdASRegistry. In theory, we should be able to create the entire configuration at runtime as a Map object, and pass that to IdASRegistry.configure. That assumes there's some way (at runtime) to know how to build that Map object.
A middle-ground alternate would place static configuration data in the config file, then at runtime, after populating the ConfigurationHandler, get the Map (ConfigurationHandler.getSettings), inject the remaining (dynamic) config settings into the Map, pass that updated Map back into ConfigurationHandler.config, and continue as normal.
At least I think that should work -- it might be a good exercise to test it with the BasicIdAS deployment.
So, we may need to flesh out our capabilities in these areas. We can access attributes in IdAS, and we can get/set policy on a context factory (though we've yet to demonstrate what that looks like), but we don't yet have the ability to express policy at the Context or DigitalSubject level. This is stuff that has sort of been on the back burner.>>> Anthony Nadalin <
drsecure@xxxxxxxxxx> 11/28/07 2:00 PM >>>
Not seeing any value with IGF, we already have claims and policy that can express what IGF is supposed to be able to express, so maybe the IGF folks can just pickup what has been done with defining the claims.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
<IMAGE.gif>
<IMAGE.gif>
From: | |
<IMAGE.gif>
To: | |
<IMAGE.gif>
Date: | <IMAGE.gif>
11/28/2007 02:45 PM |
<IMAGE.gif>
Subject: | <IMAGE.gif>
[higgins-dev] Notes from a teleconf meeting wrt IGF |
I'll start a new thread (continuing an old one) on Idas API extensibility which was one of the work items that came from the call.
<IMAGE.gif><IMAGE.gif>_______________________________________________
higgins-dev mailing list
