Anyone using Shibboleth with JAMF?
Mark Cairney
Mark.Cairney at ed.ac.uk
Thu Jun 8 12:35:46 EDT 2017
Hi,
Just to let you know that I've got this working using a
CustomNameIDGenerator.
I added the following to my saml-nameid.xml:
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:omitQualifiers="true"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
p:attributeSourceIds="uid">
<property name="activationCondition">
<bean parent="shibboleth.Conditions.RelyingPartyId"
c:candidate="https://uoe.jamfcloud.com/saml/metadata" />
</property>
</bean>
And to my relying-party.xml (which I already had):
<bean parent="RelyingPartyByName"
c:relyingPartyIds="https://uoe.jamfcloud.com/saml/metadata">
<property name="profileConfigurations">
<list>
<!-- <bean parent="SAML2.SSO" p:encryptAssertions="never"
p:signAssertions="never" p:encryptNameIDs="never" p:signResponses="true"
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
-->
<bean parent="SAML2.SSO" p:encryptAssertions="never"
p:signAssertions="never" p:encryptNameIDs="never"
p:signResponses="never"
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
<ref bean="SAML2.Logout" />
</list>
</property>
</bean>
Finally my saml-nameid.properties still had these lines commented out:
idp.nameid.saml2.legacyGenerator = shibboleth.LegacySAML2NameIDGenerator
idp.nameid.saml1.legacyGenerator =
shibboleth.LegacySAML1NameIdentifierGenerator
Once I uncommented them it all burst into life. This is slightly
confusing as I thought this was the non-legacy approach but hey-ho :)
Thanks to Scott and this pain I now know a lot more about NameIDs than I
did 2 days ago too so I suppose it's not all bad!
@Matt I haven't seen that bug as yet- we're using the cloud hosted JAMF
instance. It could be that this is running a rolling version of the
software although it does appear to have bugs of it's own (I consider
the fact I've got to go through this song and dance with nameIDs as a
bug for example when the config portal has the option to look in an
attribute- this option doesn't actually appear to do anything).
Kind regards,
Mark
On 07/06/17 21:50, Matt Brennan wrote:
> 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
> <mailto:cantor.2 at osu.edu>> wrote:
>
> On 6/7/17, 2:44 PM, "users on behalf of Mark Cairney"
> <users-bounces at shibboleth.net <mailto:users-bounces at shibboleth.net>
> on behalf of Mark.Cairney at ed.ac.uk <mailto: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 <mailto:users-bounces at shibboleth.net>
> on behalf of Mark.Cairney at ed.ac.uk <mailto: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
> <mailto:users-unsubscribe at shibboleth.net>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> <mailto:users-unsubscribe at shibboleth.net>
>
>
>
>
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk
PGP: 0x435A9621
*******************************/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/users/attachments/20170608/622c177e/attachment-0001.sig>
More information about the users
mailing list