Anyone using Shibboleth with JAMF?

[Cantor, Scott]

On 6/7/17, 2:44 PM, "users on behalf of Mark Cairney" <users-bounces at shibboleth.net on behalf of Mark.Cairney at ed.ac.uk> wrote:

> Brilliant- thanks for explaining the differences between the approaches 
> and allaying my fears re: breaking existing config. I'll try doing it 
> using the V3 approach and report back with (hopefully) a working config.

Two points:

- just don't comment out the legacy properties [1] in saml-nameid.properties and existing behavior shouldn't change
- when in doubt, the new aacli script in bin/ will do something the old one didn't; if you pass the --saml2 or --saml1 flag it will show you the NameID it's going to generate for that SP too, not just the AttributeStatement.

The exception is for an SP that's passing a NameIDPolicy element in its requests to trigger the Format to use, but that's almost never intentional or desired anyway.

-- Scott

[1]
idp.nameid.saml2.legacyGenerator = shibboleth.LegacySAML2NameIDGenerator
idp.nameid.saml1.legacyGenerator = shibboleth.LegacySAML1NameIdentifierGenerator



On 07/06/2017 19:26, Cantor, Scott wrote:
> On 6/7/17, 2:06 PM, "users on behalf of Mark Cairney" <users-bounces at shibboleth.net on behalf of Mark.Cairney at ed.ac.uk> wrote:
>
>> I've had a look but from what I can tell the UK Federation still
>> requires this to be done the old-fashioned way for
>> backwards-compatibility for the only other nameID attribute we use,
>> eduPersonTargetedID:
> That's passing a NameID inside a SAML Attribute. Passing a NameID in the subject is an entirely different animal, and the V3 change was for cleaning up that use case, not passing XML blobs inside Attributes.
>   
>> As far as I'm aware "legacy" means it should still work?
> It does, but it (generating NameIDs in the resolver) will be gone in V4. That is, again, not the same thing as generating SAML Attributes that contain NameID values. If this all seems like a mess, it is. I can't force people to stop doing things, I can only tell them they're horrible historical errors and hope they stop.
>
> But your use case has nothing to do with eduPersonTargetedID. If you want to use the resolver to generate a custom NameID, you can (until V4), I'm just stating that the documentation for how to do this in V3 is for doing it a different way, and is, I think, much more explicit than anything older, so I suggested you consider it if you don't know how to do it the way we no longer suggest.
>
>> I'd rather not have to completely re-factor how we generate NameIDs just
>> to get one odd SP to work
> If you had things working, it should still work, and I would have assumed that you had other custom NameIDs handled for other SPs. If not, then this is a pretty common problem people have making it work for reasons I have never been able to understand, and all I can say is that the documentation for V3 was written to hopefully provide a more concrete set of steps to follow. It may not be a "better" way, but I believe it's documented better.
>
>> Can the V3 approach happily co-exist with the existing V2-style config-
>> what we don't want is to break existing services in order to get this
>> one working even with Dev/Test IdPs available.
> It co-exists (it already is, you can't get transient NameIDs out of the resolver no matter what your resolver config includes). Generators you define or uncommment produce what you tell them to, when/if you tell them to, and if a Format is requested that a generator can't produce then it will look for a released Attribute with a deprecated String->NameID encoder as before.
>
> -- Scott
>
>


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net