Persistent NameID generation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Persistent NameID generation

Boyd, Todd M.

I’ve been wracking my brain with this over the last several days (not including the weekend, thankfully). I’m trying to get Shib IDP to generate a persistent NameID using our campusPermanentId attribute, but I’m seeing this in the logs:

 

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:286] - Profile Action AddNameIDToSubjects: Attempting to add NameID to outgoing Assertion Subjects

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.common.profile.logic.AbstractNameIDPolicyPredicate:218] - Policy checking disabled for NameIDPolicy with Format urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:82] - Metadata specifies the following formats: [urn:oasis:names:tc:SAML:2.0:nameidformat:persistent]

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:323] - Profile Action AddNameIDToSubjects: Candidate NameID formats: [urn:oasis:names:tc:SAML:2.0:nameidformat:persistent]

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:396] - Profile Action AddNameIDToSubjects: Trying to generate NameID with Format urn:oasis:names:tc:SAML:2.0:nameidformat:persistent

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.common.profile.impl.ChainingNameIdentifierGenerator:106] - Trying to generate identifier with Format urn:oasis:names:tc:SAML:2.0:nameidformat:persistent

2018-04-30 12:46:47,115 - DEBUG [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:341] - Profile Action AddNameIDToSubjects: Unable to generate a NameID, leaving empty

 

There are no errors in the idp-process.log file, so as far as I can tell, it’s not having any issues with the configuration. I uncommented the SAML2PersistentGenerator bean in saml-nameid.xml, and I’ve set the following values in saml-nameid.properties:

 

idp.persistentId.sourceAttribute = campusPermanentId

idp.persistentId.salt = (some salt value here)

 

The rest of the file is commented out, relying on defaults, though I’ve tried tweaking those settings to be explicit, as well—such as releasing the attribute to this SP and using filtered attributes as well as specifying the encodedSalt value.

 

We release the campusPermanentId attribute to other SPs (and I’ve experimented by releasing the attribute to this particular SP), so I know the attribute is being retrieved and that it does have a value. I’m rather confused as to what could be the problem. Any suggestions on where else I could check to troubleshoot further?

 

 

-Todd


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Cantor, Scott E.
> Any suggestions on where else I could
> check to troubleshoot further?

It isn't likely you uncommented the generator bean based on that, there are enough DEBUG log lines in there that should show up.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Boyd, Todd M.
Here's the entire shibboleth.SAML2NameIDGenerators section of saml-nameid.xml:

        <util:list id="shibboleth.SAML2NameIDGenerators">

                <ref bean="shibboleth.SAML2TransientGenerator" />

                <ref bean="shibboleth.SAML2PersistentGenerator" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oid:1.3.6.1.4.1.32548.1.1.2"
                        p:attributeSourceIds="#{ {'campusPermanentId'} }" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                        p:attributeSourceIds="#{ {'mail'} }" />

        </util:list>

Was there something else I needed to add, or is this from an older version of the config? Should it be a <bean /> element and not a <ref /> element for some reason?

-Todd


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 1:39 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

> Any suggestions on where else I could
> check to troubleshoot further?

It isn't likely you uncommented the generator bean based on that, there are enough DEBUG log lines in there that should show up.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Karla Borecky
Hi Boyd,

I don't know if you mean the rest of your saml-nameid.properties file was literally commented out, but under my persistentId source attribute and salt, there is this line

idp.persistentId.algorithm = SHA

The only other thing I can think of is, are you releasing the source attribute in your attribute filter?

cheers,
Karla B

On Mon, Apr 30, 2018 at 2:56 PM, Boyd, Todd M. <[hidden email]> wrote:
Here's the entire shibboleth.SAML2NameIDGenerators section of saml-nameid.xml:

        <util:list id="shibboleth.SAML2NameIDGenerators">

                <ref bean="shibboleth.SAML2TransientGenerator" />

                <ref bean="shibboleth.SAML2PersistentGenerator" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oid:1.3.6.1.4.1.32548.1.1.2"
                        p:attributeSourceIds="#{ {'campusPermanentId'} }" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                        p:attributeSourceIds="#{ {'mail'} }" />

        </util:list>

Was there something else I needed to add, or is this from an older version of the config? Should it be a <bean /> element and not a <ref /> element for some reason?

-Todd


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 1:39 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

> Any suggestions on where else I could
> check to troubleshoot further?

It isn't likely you uncommented the generator bean based on that, there are enough DEBUG log lines in there that should show up.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]



--
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Cantor, Scott E.
In reply to this post by Boyd, Todd M.
> Here's the entire shibboleth.SAML2NameIDGenerators section of saml-
> nameid.xml:

Whatever you're using, I don't think it's that, the log just doesn't reflect that.

> Was there something else I needed to add, or is this from an older version of
> the config? Should it be a <bean /> element and not a <ref /> element for
> some reason?

No.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Boyd, Todd M.
In reply to this post by Karla Borecky

Boyd’s my last name – our corporate email uses reverse order for sorting. :) At any rate, I tried it with “SHA” as the algorithm, but that is the default, anyway. It shouldn’t matter.

 

 

-Todd

 

From: users <[hidden email]> On Behalf Of Karla Borecky
Sent: Monday, April 30, 2018 2:19 PM
To: Shib Users <[hidden email]>
Subject: Re: Persistent NameID generation

 

Hi Boyd,

 

I don't know if you mean the rest of your saml-nameid.properties file was literally commented out, but under my persistentId source attribute and salt, there is this line

 

idp.persistentId.algorithm = SHA

 

The only other thing I can think of is, are you releasing the source attribute in your attribute filter?

 

cheers,

Karla B

 

On Mon, Apr 30, 2018 at 2:56 PM, Boyd, Todd M. <[hidden email]> wrote:

Here's the entire shibboleth.SAML2NameIDGenerators section of saml-nameid.xml:

        <util:list id="shibboleth.SAML2NameIDGenerators">

                <ref bean="shibboleth.SAML2TransientGenerator" />

                <ref bean="shibboleth.SAML2PersistentGenerator" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oid:1.3.6.1.4.1.32548.1.1.2"
                        p:attributeSourceIds="#{ {'campusPermanentId'} }" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                        p:attributeSourceIds="#{ {'mail'} }" />

        </util:list>

Was there something else I needed to add, or is this from an older version of the config? Should it be a <bean /> element and not a <ref /> element for some reason?

-Todd



-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 1:39 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

> Any suggestions on where else I could
> check to troubleshoot further?

It isn't likely you uncommented the generator bean based on that, there are enough DEBUG log lines in there that should show up.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]



 

--

Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063

 

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Boyd, Todd M.
In reply to this post by Cantor, Scott E.
Sorry for my confusion -- you don't think that configuration is the issue, or you don't think that's my actual configuration?


-Todd


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 2:35 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

> Here's the entire shibboleth.SAML2NameIDGenerators section of saml-
> nameid.xml:

Whatever you're using, I don't think it's that, the log just doesn't reflect that.

> Was there something else I needed to add, or is this from an older
> version of the config? Should it be a <bean /> element and not a <ref
> /> element for some reason?

No.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Cantor, Scott E.
> Sorry for my confusion -- you don't think that configuration is the issue, or
> you don't think that's my actual configuration?

Not your configuration. That doesn't mean it's not on disk, but it isn't being used. If the plugin didn't generate, it would log a reason why, even if just on DEBUG, so there's no indication it ran.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Karla Borecky
In reply to this post by Boyd, Todd M.
Sorry! I should have noticed that.

On Mon, Apr 30, 2018 at 3:55 PM, Boyd, Todd M. <[hidden email]> wrote:

Boyd’s my last name – our corporate email uses reverse order for sorting. :) At any rate, I tried it with “SHA” as the algorithm, but that is the default, anyway. It shouldn’t matter.

 

 

-Todd

 

From: users <[hidden email]> On Behalf Of Karla Borecky
Sent: Monday, April 30, 2018 2:19 PM
To: Shib Users <[hidden email]>
Subject: Re: Persistent NameID generation

 

Hi Boyd,

 

I don't know if you mean the rest of your saml-nameid.properties file was literally commented out, but under my persistentId source attribute and salt, there is this line

 

idp.persistentId.algorithm = SHA

 

The only other thing I can think of is, are you releasing the source attribute in your attribute filter?

 

cheers,

Karla B

 

On Mon, Apr 30, 2018 at 2:56 PM, Boyd, Todd M. <[hidden email]> wrote:

Here's the entire shibboleth.SAML2NameIDGenerators section of saml-nameid.xml:

        <util:list id="shibboleth.SAML2NameIDGenerators">

                <ref bean="shibboleth.SAML2TransientGenerator" />

                <ref bean="shibboleth.SAML2PersistentGenerator" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oid:1.3.6.1.4.1.32548.1.1.2"
                        p:attributeSourceIds="#{ {'campusPermanentId'} }" />

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
                        p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                        p:attributeSourceIds="#{ {'mail'} }" />

        </util:list>

Was there something else I needed to add, or is this from an older version of the config? Should it be a <bean /> element and not a <ref /> element for some reason?

-Todd



-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 1:39 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

> Any suggestions on where else I could
> check to troubleshoot further?

It isn't likely you uncommented the generator bean based on that, there are enough DEBUG log lines in there that should show up.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]



 

--

Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063

 

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]



--
Karla Borecky
Systems Administrator
ITS
Smith College
Northampton, MA 01063



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Boyd, Todd M.
In reply to this post by Cantor, Scott E.
I do know that the other configuration in that <util:list /> element is being loaded, since we have SPs that use the specific attribute-sourced NameIDs defined within, and I don't see any ERRORs in the log at all--let alone related to saml-nameid.xml--even when I dial everything up to 11 with DEBUG settings in the logging configuration. I'm not sure where else to look in order to ensure that the plugin is being loaded.

I don't suppose there's any use trying to tweak the configuration for the generator if the generator itself isn't being loaded. Is there anything (in Shibboleth "userland" conf/* rather than the system/* configuration) other than saml-nameid.properties and saml-nameid.xml that would govern the use of the plugin?


-Todd


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 3:09 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

> Sorry for my confusion -- you don't think that configuration is the
> issue, or you don't think that's my actual configuration?

Not your configuration. That doesn't mean it's not on disk, but it isn't being used. If the plugin didn't generate, it would log a reason why, even if just on DEBUG, so there's no indication it ran.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Cantor, Scott E.
In looking at the message you sent in a non-plaintext form, I think you have a bogus character in your metadata so it's specifying a non-matching NameID Format. That explains why it's not running. I don't read HTML email so the message was ASCII-fied before I saw it.

I glanced at it in the archive at https://marc.info/?l=shibboleth-users&m=152511246325192&w=2 and I can see the bogosity.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Boyd, Todd M.
Good grief. Yes, it looks like a Windows codepage "dash that's not a real ASCII dash" snuck its way in there. Oh, how I wish Microsoft Office wasn't a thing. Pardon me while I slam my face through an oak table.

Thanks!


-Todd


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, April 30, 2018 3:44 PM
To: Shib Users <[hidden email]>
Subject: RE: Persistent NameID generation

In looking at the message you sent in a non-plaintext form, I think you have a bogus character in your metadata so it's specifying a non-matching NameID Format. That explains why it's not running. I don't read HTML email so the message was ASCII-fied before I saw it.

I glanced at it in the archive at https://marc.info/?l=shibboleth-users&m=152511246325192&w=2 and I can see the bogosity.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Persistent NameID generation

Cantor, Scott E.
> Good grief. Yes, it looks like a Windows codepage "dash that's not a real ASCII
> dash" snuck its way in there. Oh, how I wish Microsoft Office wasn't a thing.
> Pardon me while I slam my face through an oak table.

File a RFE and we'll add tracing, it would be noisy on DEBUG but it can log the Format comparisons the conditions run. It's pretty obvious in context what went wrong if something actually logs "Foo != Foo, skipping" when they look identical.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Boyd, Todd M.
Will do. Our current setup is only to release information to SPs we have explicitly allowed, and so I got an error attempting to log into the JIRA site. I should be able to get the Shibboleth Issues entity ID added to our configuration and push it through the build pipeline soon. (Ultimate goal would be to release at least the base attributes to all InCommon member SPs, but there are some politics involved in that.) Thanks again!

________________________________
From: users <[hidden email]> on behalf of Cantor, Scott <[hidden email]>
Sent: Monday, April 30, 2018 4:02:50 PM
To: Shib Users
Subject: RE: Persistent NameID generation

> Good grief. Yes, it looks like a Windows codepage "dash that's not a real ASCII
> dash" snuck its way in there. Oh, how I wish Microsoft Office wasn't a thing.
> Pardon me while I slam my face through an oak table.

File a RFE and we'll add tracing, it would be noisy on DEBUG but it can log the Format comparisons the conditions run. It's pretty obvious in context what went wrong if something actually logs "Foo != Foo, skipping" when they look identical.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Peter Schober
In reply to this post by Boyd, Todd M.
* Boyd, Todd M. <[hidden email]> [2018-04-30 22:59]:
> Yes, it looks like a Windows codepage "dash that's not a real ASCII
> dash" snuck its way in there. Oh, how I wish Microsoft Office wasn't
> a thing.

Are you saying you're editing SAML Metadata with Microsoft Office?
There must be better tools for that.

If all else fails try SciTE which (last time I had to use a MS-Windows
maschine) works without installation and provides syntax highlighing,
https://scintilla.org/SciTE.html
It also doesn't mess with your dashes. ;)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Boyd, Todd M.
No, I am not. I copy-pasted some values from a vendor's instructional document, and that vendor was using MS Word (most likely) to build said document.


As for SciTE... I'll continue to use gVim, thanks. :) I guess I'll just have to check everything I get from vendors in ASCII instead of the default UTF-* encoding.


-Todd
________________________________
From: users <[hidden email]> on behalf of Peter Schober <[hidden email]>
Sent: Thursday, May 3, 2018 8:19:08 AM
To: [hidden email]
Subject: Re: Persistent NameID generation

* Boyd, Todd M. <[hidden email]> [2018-04-30 22:59]:
> Yes, it looks like a Windows codepage "dash that's not a real ASCII
> dash" snuck its way in there. Oh, how I wish Microsoft Office wasn't
> a thing.

Are you saying you're editing SAML Metadata with Microsoft Office?
There must be better tools for that.

If all else fails try SciTE which (last time I had to use a MS-Windows
maschine) works without installation and provides syntax highlighing,
https://scintilla.org/SciTE.html
It also doesn't mess with your dashes. ;)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Peter Schober
* Boyd, Todd M. <[hidden email]> [2018-05-03 15:40]:
> I copy-pasted some values from a vendor's instructional document,
> and that vendor was using MS Word (most likely) to build said
> document.

Nasty. That (messed-up SAML constants) wouldn't have been caught by
any of my tooling either...

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Boyd, Todd M.
I've filed an Improvement issue! I hope I did a halfway decent job of explaining what it is I'm asking for. If not, I'm more than happy to adjust/rewrite it.


https://issues.shibboleth.net/jira/browse/IDP-1290



Regards,


-Todd

________________________________
From: users <[hidden email]> on behalf of Peter Schober <[hidden email]>
Sent: Thursday, May 3, 2018 8:52:41 AM
To: [hidden email]
Subject: Re: Persistent NameID generation

* Boyd, Todd M. <[hidden email]> [2018-05-03 15:40]:
> I copy-pasted some values from a vendor's instructional document,
> and that vendor was using MS Word (most likely) to build said
> document.

Nasty. That (messed-up SAML constants) wouldn't have been caught by
any of my tooling either...

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Persistent NameID generation

Peter Schober
In reply to this post by Peter Schober
* Peter Schober <[hidden email]> [2018-05-03 15:55]:
> * Boyd, Todd M. <[hidden email]> [2018-05-03 15:40]:
> > I copy-pasted some values from a vendor's instructional document,
> > and that vendor was using MS Word (most likely) to build said
> > document.
>
> Nasty. That (messed-up SAML constants) wouldn't have been caught by
> any of my tooling either...

JFYI, I've meanwhile added a check for that. Example at:
https://gist.github.com/peter-/0da1b53fb08e43e7bfd07e6a0b3a7f30
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]