Nameid in clear text

[Peter Schober]

* Mathew, Sunil <smathew at hbs.edu> [2020-11-02 22:03]:
> When I sent encrypted nameid to SP, it is creating a new user every
> time I login with an account because SP tries to match by the
> nameid. So I need to send the nameid in clear text.

The IDP hasn't been encrypting NameIDs since 2.1.3 released a decade
ago, so unless you explictly *enabled* encryption of NameIDs that's
not what's happened. (If you enabled it yourself you know what to do
to disable it again.)

As Alan suggested, you're mistaken about what happens here.

Btw, just how old is that IDP of yours? You're using a syntax (XML
namespaces) that shouldn't be required for one, maybe two major
releases of the software.

Guessing what exactly it is you want from your filter:

> <afp:AttributeFilterPolicy>
>   <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://bootcamp.quickbase.com" />
>   <afp:AttributeRule attributeID="quickbase_federated_id">
>     <afp:PermitValueRule xsi:type="basic:ANY" />
>   </afp:AttributeRule>
> </afp:AttributeFilterPolicy>

and resolver:

> <resolver:AttributeDefinition xsi:type="ad:PrincipalName" id="quickbase_federated_id">
>   <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="uid" />
>   <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" friendlyName="uid" />
> </resolver:AttributeDefinition>

and relying-party:

> <bean parent="RelyingPartyByName" c:relyingPartyIds="https://bootcamp.quickbase.com">
>   <property name="profileConfigurations">
>     <list>
>       <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
>       <bean parent="SAML2.SSO" p:encryptAssertions="false" p:encryptNameIDs="never" />
>     </list>
>   </property>
> </bean>

If your intention is to release the value of the "uid" attribute to
the SP as a persistent NameID the above is neither necessary (don't
re-defined your uid attribute with an SP-specific internal id) nor
sufficient, nor correct, on several accounts.
(I'll only include the severest one you won't care about at all:
Common values for "uid" do not make legal values for persistent
NameIDs, see 8.3.7 "Persistent Identifier" in the spec,
https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf)

Nothing above defines a NameID of any format, including a persistent one.

I do not recall whether you can even have attribute-sourced persistent
NameIDs (because they pretty much would always violate the SAML spec)
but either way the documenation for that would be here:
https://wiki.shibboleth.net/confluence/display/IDP4/CustomNameIDGenerationConfiguration
(If you're not running IDPv4 then look at the docuemntation for the
version of the software you're running.)

> For other SPs, I used to comment out this line in relying-party.xml
> in order to send nameid in clear text:
> <bean parent="SAML2.SSO" p:encryptAssertions="false" p:encryptNameIDs="never" />

Commenting out that line would re-enable encrypting assertions to an
SP, so couldn't possibly make things "more" clear text. That's even a
famous saying about it:

"Enabling encryption does not make things 'clear text'".
  -- me, now

> Now if I do that I am getting the following error:
> 2020-11-02 16:00:51,838 - WARN [org.opensaml.xmlsec.impl.BasicEncryptionParametersResolver:221] - Validation failure: Failed to resolve both a data and a key encryption credential
> 2020-11-02 16:00:51,838 - WARN [net.shibboleth.idp.saml.saml2.profile.impl.PopulateEncryptionParameters:343] - Profile Action PopulateEncryptionParameters: Resolver returned no EncryptionParameters

I don't know what the IDP wants to encrypt here but it's clear it
can't encrypt anything since the SP in question doesn't have a
suitable key in its metadata. So unless you *deactivate* (not
re-activate) encryption to that SP it will fail.

That does not give you bogus persistent NameIDs, yet, but we can dial
in on those after you've gotten rid of the WARNing above.

-peter