supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

[Peter Schober]

* anuptiwary <anup.kr.tiwary at gmail.com> [2018-07-27 14:26]:
> Can you please help me here, as per my understanding I have mapped
> required entry.

I told you what several of the issues are. This is about the SP's
mapping, your IDP is misconfigured.

> principalId is the userName which is supplied from idp login
> page. want this information in my request header as attribute
> value. This will resolve my issue.

You have several issues and you seem to fail to even acknowledge this
fact.

Ignoring the IDP backchannel issue, your IDP attribute definition for
your "principalId" attribute is bogus. Since you have not even tried
to offer an explanation what it is *supposed* to do I'll assume your
current attemps don't mean anthing.

If you wanted to stick with the "PrincipalName" attribute definition
(because it will always be populated, even though it suffers from
inconsistencies as it's value will be whatever the subject typed in to
the login form, verbatim) just add a SAML2String attribute encoder to
it, same as for any other attribute in your resolver config, *instead*
of the "SAML2StringNameID" and transient NameID encoder you currently
have there.

There is no standard attribute for "principalId" but you could send it
as "uid" instead. (Either comment out your attribute definition with
id="uid" thenm to avoid duplicates, or better, remove the
id="principalId" attribute definition and only go with the id="uid"
one, if you have duplicate attribute values.)

<resolver:AttributeDefinition xmlns="urn:mace:shibboleth:2.0:resolver:ad"
  id="principalId" xsi:type="PrincipalName">
  <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid"/>
</resolver:AttributeDefinition>

Make sure you release this attribute (principalId or uid, if you
followed my advise and used only uid; if in doubt release them both)
to your SP in your attribute filter.

Restart the IDP, log in to the SP and check your IDP logs.
Unless the logs say that you've released principalId (or uid) go back
and fix your mistakes until the logs say you've successfully released
them (the audit log will include the attribute names then).

Only once that works go to the SP and create a mapping for the
attribute "0.9.2342.19200300.100.1.1" and map it to "uid". Use the SP
documentation if you don't know how.

Only once your SP transaction log shows that you've successfully
recieved the "uid" attribute, add it as first (or only) value to the
REMOTE_USER precedence list in your SP's shibboleth2.xml

If all of this is correct accessing a protected resource on the SP
would show the value of principalId in httpd's access log.
(If not then not everything above is correct, and/or you have not
protected anything on the SP, yet. In that case go back and fix your
mistakes.)

Don't bother checking whether you revieced anything correctly in your
Java application before httpd does show the principalId in the httpd
access log!

Only once all the data is there in the access log but you don't see it
in your Java application you're probably using the wrong API on the
Java side.  (It should be request.getRemoteUser() or something like
that.)

Finally: If anything goes wrong re-read this email (or the
documentation) as often as needed. Unless you show clear signs of
having read and understood that I won't bother to write more.

-peter