Shibboleth Developers

["Tom Scavo" <>]

On 3/5/06, Tom Scavo 
<>
 wrote:
>
> > > where can I get the authoritative,
> > > deployment-wide domain (scope) attribute?
> >
> > The plugin API would probably have to expose that piece of data so that it
> > could be supplied at runtime from the back end, and then you could define 
> > a
> > default value to use.
>
> Sounds like another Shib 2.0 feature :-) but since I'm working with
> Shib 1.3, here's what I'll do:
>
> - I'll make the NameMapping/@qualifier attribute optional.  If it's
> omitted, I'll use idp.getProviderId() in the plugin, which is what I'm
> doing now.
>
> - I'll make the NameMapping/@template and NameMapping/@regex
> attributes required.
>
> If you add a default domain (scope) in Shib 2.0, you can relax the
> above requirement.

Actually, the requested enhancement consists of three parts:

1. Add a default domain to the IdP config
2. Modify the protocol handler to accept domain override from the deployment
3. Add placeholder %DOMAIN% in addition to %PRINCIPAL%

What you get in return is a simplified NameMapping config:

<NameMapping
  xmlns="urn:mace:shibboleth:namemapper:1.0"
  id="unspecified"
  format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
  template="%PRINCIPAL%"
  regex="(.+)"
  qualifier="https://idp.example.org/shibboleth";
  type="Principal"/>

<NameMapping
  xmlns="urn:mace:shibboleth:namemapper:1.0"
  id="email"
  format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  
template="%PRINCIPAL%@%DOMAIN%"
  
regex="([^@]+)@([^@]+)"
  qualifier="https://idp.example.org/shibboleth";
  type="Principal"/>

<NameMapping
  xmlns="urn:mace:shibboleth:namemapper:1.0"
  id="x509"
  format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"
  template="uid=%PRINCIPAL%,o=%DOMAIN%"
  regex="uid=([^,/]+),o=([^,/]+)"
  qualifier="https://idp.example.org/shibboleth";
  type="Principal"/>

The template, regex, and qualifier attribute values listed are
proposed defaults, so they can be omitted in the majority of cases.

The only bugger is WindowsDomainQualifiedName.  In that case, the
%DOMAIN% precedes the %PRINCIPAL% according to the format, so it
breaks the order of the subexpressions in the regex.  Not sure how to
reconcile that without introducing unwanted complexity.

Thanks,
Tom