SP specific password transforms?

Dylan Martin Dylan.Martin at seattlecolleges.edu
Thu Dec 1 16:58:30 EST 2016


Yay!  Thank you!

Yes, I meant username.  I was staring at the name of the bean.  D'oh!

This is great.  The which-part-does-what is what I really needed help with.

Did I mention, thanks!

-Dylan



On Thu, Dec 1, 2016 at 1:14 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > I have an IDPv3 and I need to perform different password transforms for
> two
> > different SPs.  Is there a way to say to use one transform for one SP
> and a
> > different transform for a different SP?
>
> I'm not sure you're asking what your subject says you're asking. For one
> thing there are no "password transforms", so I know you mean something
> else, but I also don't think you mean "username transforms" either really.
> That has to do with your authentication system up front, not the data you
> pass to services. I think you mean the latter.
>
> > Is there a generic or idiomatic way to make setting only apply to
> particular SPs
> > in shibboleth?
>
> Many options can be attached to relying party configurations, and other
> things can be triggered by activation conditions that can reference the SP,
> and then there are lots of more explicit things that are geared entirely
> around the SP.
>
> One setting that isn't done that way is the username transform feature and
> that really would almost never make any sense.
>
> The canonicalized principal name resulting from authentication *can* be
> normalized in an SP-specific way, but that is almost always also a terrible
> idea and still isn't needed to just control the data sent to SPs. The
> normalized authenticated name should be based on how you need to access
> your IDM-supplied data in the attribute resolver, so is often dictated by
> what you need to have to search directories or databases. That is rarely SP
> specific.
>
> > We're a campus within a district.  The district recently set up a
> district-wide
> > AD server, and I'm using that as the LDAP back-end for my shib system.
> Our
> > Google apps domain is different from the district domain, but I've set up
> > provisioning so the Google accounts have the same username part of the
> > user's email address.
>
> Right, but that affects nothing but what you send to Google, and that's a
> SAML NameID that you compute from an IdPAttribute you produce in your
> attribute resolver. Generally that is where you handle this problem. You
> build up an IdPAttribute from an AttributeDefinition that has what you need
> for Google, you release that Google via the filter policy, and you generate
> a NameID of an appropriate Format using that attribute's ID as the source.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161201/92c7efc8/attachment.html>


More information about the users mailing list