Shibboleth Developers

[Chad La Joie <>]

I think I understand what you're saying Tom.  Let me offer a suggestion. 
 Anyone running an IdP has to configure the IdP, the build doesn't do 
that.  Instead, why don't you treat the configuration of your name 
mapper the same way that all the other components like this (name 
mappers, artifact mappers, protocol handlers, etc) are configured in the 
IdP?  Just include some number of elements within the NameMapping 
element in the config file the use them in your mapper.  So you might 
have a name mapper deceleration like this:

<NameMapping id="some_string" class="gridshib.name.mapper.class">
  <GridMapsDirectory>/home/gridshib/gridmaps/</GridMapsDirectory>
  <GridMapFile>/etc/gridshib/gridmap-default</GridMapFile>
</NameMapping>

You can include any number of sub-elements in the NameMapping element, 
they're just passed to the Mapper when it's initialized.

This way your name mapper behaves just like the standard ones that come 
with Shib and you can put your files or directory of files wherever you 
want.

Tom Scavo wrote:
> I guess the best thing for me to do at this point is to fall back on
> first principles and try to describe (again) the GridShib requirements
> with respect to installation, configuration, maintenance, and so
> forth.  If the requirements can't be met, that's fine, but at least it
> won't be because they're not well defined.  I'll try to keep this as
> simple as I can.
>
> GridShib has its own metadata file, which contains role descriptors
> for every grid service provider the IdP trusts.  Initially, we will
> ship GridShib with a metadata stub containing a single role
> descriptor, that of a test grid service provider.  Over time, other
> role descriptors will be added to this metadata file.  In fact, we
> expect this metadata file to be actively maintained by the IdP
> sysadmin.
>
> The GridShib plugin, an implementation of NameIdentifierMapping, loads
> name mappings from files called gridmap files.  Gridmap files are
> ordinary text files, loaded and parsed at startup.  There is (or will
> be) a refresh capability so that gridmap files are auto-reloaded
> on-the-fly as needed.
>
> Like the metadata file, the gridmap files are actively maintained by
> the IdP sysadmin.  Entries may be added, modified, or deleted from
> existing gridmap files.  New gridmap files may be created (by
> definition gridmap filenames start with the characters "gridmap")
> while old gridmap files may be deleted, all of which will be handled
> dynamically by the plugin.
>
> Okay, I really should stop here because now you can mostly infer the
> requirements by reading between the lines.  I will emphasize, however,
> the obvious requirement that the definitive versions of the metadata
> and gridmap files must be totally separate from Shibboleth.  They can
> not live in the Shibboleth installation directory, nor can they reside
> in a tomcat webapp directory (both of which are volatile).  Instead,
> the metadata and gridmap files must be stored in a home directory
> known only to GridShib (otherwise we run the risk of some process
> clobbering them).
>
> I appreciate what you're trying to do with the custom/ directory, and
> I'm sure many extension developers will find it useful, but unless I'm
> missing something it doesn't help our use case very much since the
> definitive versions of the metadata and gridmap files are not in the
> custom/ directory but rather in the GridShib home directory.  Unless
> we can work out a system where each extension has its own home
> directory, I'm afraid we won't be able to make much use of the build
> process you propose.
>
> I apologize for not making our requirements more clear before (this
> has been and continues to be an ongoing process).  I realize you're
> trying to get Shib 1.3 out of the door, so if this isn't doable in the
> short timeframe you have before you, or if you feel ours is not a
> generally applicable use case, that's fine, we'll figure something
> else out.
>
> Tom

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124