Anyone using Shibboleth with JAMF?

[Matt Brennan]

Hi Mark,

  I do have it working on my installation, but I have an on-prem JSS. I
would assume it's the same software, though, so happy to help if I can.

  One heads up, they have a bug in their current version with SAML. If you
navigate directly to a link without being logged in, it will redirect you
to your SAML login. After the call back with the assertion, it will log you
in, show the page, and immediately log you out. Took me a few minutes to
realize what was going on there. You can work around it by navigating to
the normal login page (without a relay state), logging in, and then
clicking the link.

-Matt


On Wed, Jun 7, 2017 at 2:49 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
>
> --
> 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/20170607/3ceb1f04/attachment.html>