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 13:05]:
> As I can see in idp-process log. there is attribute principalId which is
> released by idp but seems my attribute-mapping or some other mapping does
> not hold true to pass it to SP.


> 
> I have now configured below line (where principleId is now added ) after
> looking at idp-process logs.
> 
> <ApplicationDefaults entityID="http://localhost:8080/WebUI"
>       REMOTE_USER="principalId sn eppn persistent-id targeted-id NameID"
> signing="false" encryption="false" attributePrefix="AJP_" 
> homeURL="http://localhost:8080/WebUI">
> 


> Please once look at below idp-process.logs if you could find
> something in it and guide me through.

It's the idp-audit.log that will tell you what attributes where
released (it's just copied to idp-process.log, too, by default).

> 16:18:27.875 - DEBUG
> [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:114]
> - Filtered attributes for principal testuser.  The following attributes
> remain: [principalId]

So far, so good.

> 16:18:27.877 - DEBUG
> [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:263]
> - Attribute principalId was not encoded (filtered by query, or no SAML2AttributeEncoder attached).
> 16:18:27.877 - DEBUG
> [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:129]
> - No attributes remained after encoding and filtering by value, no attribute
> statement built

Here's what went wrong, if you wanted to release the data as an attribute.

> 16:18:27.883 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:868]
> - Using attribute 'principalId' supporting NameID format
> 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' to create the NameID
> for relying party 'http://localhost:8080/WebUI'

What are you trying to do here? You never populate transient NameIDs
from attributes.

If you want to use transient NameIDs (see the SAML spec for details)
use them as is, there's nothing wrong with the IDP's implementation.
If you want to use something other than transient NameIDs, well, use
something other than transient NameIDs.

Why are you messing with NameIDs at all?
Just use attributes and be done with.

> 16:18:27.938 - INFO [Shibboleth-Audit:1028] -
> 20180727T104827Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_28da556246a0427a1c89025c5225b37d|http://localhost:8080/WebUI|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://localhost:8443/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_2e554f90055930e2a4b43827ac27cb0b|testuser|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||testuser|_e67c13cf510ab68b82e6c4486bdb8adc,|

It's not clear to me from that log whether the value you want (whatver
the value of your "principalId" is) has successfully been sent as a
transient NameID. Even if if did that would be wrong.

So how about you start at the beginning, telling us jusz what exactly
you're doing (and why)?
What is this "principalId", where do the values come from? If that's
what the subject enters during login that's not a legal value for
transient NameIDs.

-peter