Shibboleth Developers

[Etan Weintraub <>]

I understand...and I'm not sure is my answer. I can see it making it easier 
for initial deployments, but I think when I have to add attributes later, I 
see myself forgetting that I have to modify attribute-encoder.xml also, hence 
why I wanted the option of keeping it in the single file.

-Etan E. Weintraub
Team Leader - Enterprise Authentication
Senior Systems Engineer - Enterprise Directory
IT@Johns
 Hopkins
Johns Hopkins at Mt. Washington
5801 Smith Ave.
Suite 3110B
Baltimore, MD 21209
Phone: 410-735-7945
E-mail: 



-----Original Message-----
From: Chad La Joie 
[mailto:]
 
Sent: Tuesday, February 02, 2010 4:42 PM
To: 

Subject: Re: [Shib-Dev] attribute-encoder.xml?

In theory, yes, that would be possible.  It would also be possible to 
provide a one-shot script to take an existing file and split it up. 
Nate is just trying to get a feel for whether this might make things 
easier for people.

On 2/2/10 4:36 PM, Etan Weintraub wrote:
> Would it be possible to support it both ways? That way admins wouldn't 
> necessarily have to change their files, and could opt to do this later to 
> clean up their files.
>
> -Etan E. Weintraub
> Team Leader - Enterprise Authentication
> Senior Systems Engineer - Enterprise Directory
> IT@Johns
>  Hopkins
> Johns Hopkins at Mt. Washington
> 5801 Smith Ave.
> Suite 3110B
> Baltimore, MD 21209
> Phone: 410-735-7945
> E-mail: 
> 
>
>
> -----Original Message-----
> From: Nate Klingenstein 
> [mailto:]
> Sent: Tuesday, February 02, 2010 4:32 PM
> To: 
> 
> Subject: [Shib-Dev] attribute-encoder.xml?
>
> Shibbolizers,
>
> An idea struck me while trolling through another attribute-
> resolver.xml file and talking to Chad.  Would it be better if
> attribute encoders were maintained in a separate file, like attribute
> filters?
>
> There's a lot of visual clutter that is added by the inclusion of the
> attribute encoders in the middle of attribute definitions.  They're
> very rarely changed by deployers (though new ones are added), while
> other parts of the resolver file, such as data connector dependencies,
> would be changed more often.  Furthermore, they're a distinct part of
> the attribute system, though, and are only used later in the process,
> outside of the resolver itself.
>
> I'd really like to see the encoders placed into a separate attribute-
> encoder.xml file.  An attribute definition would then look like(though
> the syntax might be further collapsible):
>
>       <resolver:AttributeDefinition id="uid" xsi:type="Simple" 
> xmlns="urn:mace:shibboleth:2.0:resolver:ad
> "
>           sourceAttributeID="uid">
>           <resolver:Dependency ref="myLDAP" />
>       </resolver:AttributeDefinition>
>
> and the corresponding part of attribute-encoder.xml would look like:
>
> <AttributeEncoder attributeID="uid">
>
>           <resolver:AttributeEncoder xsi:type="SAML1String" 
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder
> "
>               name="urn:mace:dir:attribute-def:uid" />
>
>           <resolver:AttributeEncoder xsi:type="SAML2String" 
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder
> "
>               name="urn:oid:0.9.2342.19200300.100.1.1"
> friendlyName="uid" />
>
> </AttributeEncoder>
>
> I'd also like the attribute-encoder.xml defaults to be uncommented in
> the distribution.  Since the corresponding attributes are already
> commented out, I can't see any harm from doing so, but it would make
> the IdP more approachable to deployers.
>
> Anyone in favor or against?
> Nate.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

Attachment: PGP.sig
Description: PGP signature