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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

anuptiwary
While login through idp login screen user is authenticated (used Apache
directory server for user information) successfully and saml response is
sent from idp to SP at service provider end I getting below error -

supplied TrustEngine failed to validate SSL/TLS server certificate
...
complete certificated detail(s) e.g.
 Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:8a:85:16:56:f2:92:4e:8a:37:79:e1:35:26:25:
                    34:39:65:9f:61:d5:9e:cf:4a:88:09:11:47:8b:86:
                    8b:a5:15:79:55:3f:bf:c9:1e:aa:a0:d2:a4:5d:d2:

.....
.....

ERROR Shibboleth.AttributeResolver.Query [29]: exception during SAML query
to https://localhost:8443/idp/profile/SAML2/SOAP/AttributeQuery:
CURLSOAPTransport failed while contacting SOAP endpoint
(https://localhost:8443/idp/profile/SAML2/SOAP/AttributeQuery): SSL
certificate problem: application verification failure

Below is the HLD diagram for component integration - as I am using httpd
server infront
me <http://shibboleth.1660669.n2.nabble.com/file/t398706/HLD.png>

Any help would be much appreciated. I am stuck at same level since long and
not getting any clue, renewed idp certificate multiple time but no success.



--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

Peter Schober
* anuptiwary <[hidden email]> [2018-07-26 12:31]:
> ERROR Shibboleth.AttributeResolver.Query [29]: exception during SAML query
> to https://localhost:8443/idp/profile/SAML2/SOAP/AttributeQuery:
> CURLSOAPTransport failed while contacting SOAP endpoint
> (https://localhost:8443/idp/profile/SAML2/SOAP/AttributeQuery): SSL
> certificate problem: application verification failure

Why are you using Attribute Queries at all? Is that by design or
unintentional? (If the latter: "If it hurts stop doing it.")

If intentional, what's the certificate the IDP presents on port 8443?
How exactly did you configure the IDP (or Tomcat) wrt that port? Did
you configure Tomcat to use the idp-backchannel.p12 key pair for 8443?

Does the SP have this certificate available from the IDP's metadata?

From the image you sent it's not clear at all how the IDP is exposed
to the network SP and what role Apache httpd plays here.

And all of this is simply a demo setup, since you seem to be running
the IDP and the SP all on the same box? Or what else is this for?

-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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

anuptiwary
Thank you! for response peter. Expecting your further revert, kindly help me
out.

Please find below inline reply
shibboleth2.xml
<http://shibboleth.1660669.n2.nabble.com/file/t398706/shibboleth2.xml>  

*Q.* Why are you using Attribute Queries at all? Is that by design or
unintentional? (If the latter: "If it hurts stop doing it.")
*AnupTiwary>>* Since it's idp initiated SSO so in response we are expecting
user header information in the form of attribute.
or else how to use the same session to redirect it to application dashboard
instead of login page?
if I remove below line from shibboleht2.xml, then I am not getting any
certificate error which is obvious.
...
<AttributeResolver type="Query" subjectMatch="true"/>

*Q.* If intentional, what's the certificate the IDP presents on port 8443?
*AnupTiwary>>*Used the same certificate which was generated while installing
the idp. (Renewed after configuration as well).
configured in tomcat using connector port for AJP protocol, since I am using
httpd as proxy. Below is the tomcat server.xml configuration for idp
certificate.
...
<Connector SSLEnabled="true"
SSLImplemention="edu.internet2.middleware.security.tomcat7.DelegateToApplicationJSSEImplementation"
clientAuth="false" keystoreFile="D:\opt\shibboleth-idp\credentials\idp.jks"
keystorePass="changeit" maxThreads="150" port="8443"
protocol="org.apache.coyote.http11.Http11Protocol" scheme="https"
secure="true" sslProtocol="TLS"/>

<Connector packetSize="65536" port="8009" protocol="AJP/1.3"
redirectPort="8443" tomcatAuthentication="false"/>
       
*Q.*How exactly did you configure the IDP (or Tomcat) wrt that port? Did you
configure Tomcat to use the idp-backchannel.p12 key pair for 8443?
*AT >>* Same as above

*Q.* Does the SP have this certificate available from the IDP's metadata
*AT>>* I have uploaded (Manually copied idp-metadata.xml) in sp installation
path (C:\opt\shibboleth-sp\etc\shibboleth)
        and below is the configuration for shibboleth.xml to present idp metadata
       
        <MetadataProvider type="XML" validate="true" file="idp-metadata.xml"/>
        for specifics I am attaching shibboleht2.xml for your reference.
       
*Q.* From the image you sent it's not clear at all how the IDP is exposed to
the network SP and what role Apache httpd plays here.
*AT>>* Since it is on the same network and same box and configured withing
the shibboleht2.xml so as per my thinking it should work, if you have
diffrent thoughts then please suggest.
Apache httpd is used for to implement proxy to redirect the to flow to AJP
connector and further additional application configuration.

*Q.* And all of this is simply a demo setup, since you seem to be running
the IDP and the SP all *AT>>* on the same box? Or what else is this for?
This is POC so that we could move the same approach in actual environment.

Please help me out on this, struggling since long at same point. as it seems
I am almost there but due to lack of knowledge I am not able to think in
required direction.



--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

Peter Schober
* anuptiwary <[hidden email]> [2018-07-27 08:37]:
> *Q.* Why are you using Attribute Queries at all? Is that by design or
> unintentional? (If the latter: "If it hurts stop doing it.")
> *AnupTiwary>>* Since it's idp initiated SSO so in response we are expecting
> user header information in the form of attribute.
> or else how to use the same session to redirect it to application dashboard
> instead of login page?

Nothing here has anything to do with attribute queries. The Shib SP
will only perform queries if it does not receive attributes during
SSO. So the fact that you think you have to perform queries just means
your IDP is not configured correctly yet to send this SP any data.

> if I remove below line from shibboleht2.xml, then I am not getting any
> certificate error which is obvious.
> ...
> <AttributeResolver type="Query" subjectMatch="true"/>

Yes, remove that and move on to solving the underlying issue here,
which is the IDP not releasing anything.

> *Q.* If intentional, what's the certificate the IDP presents on port 8443?
> *AnupTiwary>>*Used the same certificate which was generated while installing
> the idp. (Renewed after configuration as well).

That's not an answer, because the IDP generates several key pairs
during install.

> configured in tomcat using connector port for AJP protocol, since I
> am using httpd as proxy. Below is the tomcat server.xml
> configuration for idp certificate.

Why are you using httpd in front of the IDP? Just because in your
artificial demo setup you have to have httpd for the SP anyway?
(You can run the IDP behind httpd, there's just no good reason to.)

> <Connector SSLEnabled="true"
> SSLImplemention="edu.internet2.middleware.security.tomcat7.DelegateToApplicationJSSEImplementation"
> clientAuth="false" keystoreFile="D:\opt\shibboleth-idp\credentials\idp.jks"
> keystorePass="changeit" maxThreads="150" port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol" scheme="https"
> secure="true" sslProtocol="TLS"/>

What version of the IDP is that? A supported IDP release does not
create an idp.jks, it will generate several key pairs (none by that
name). The one you'd give to Tomcat for the backchannel port is
idp-backchannel.p12.

Creating an IDP and SP on the same machine sounds like a test/demo
setup. But why would you do a demo setup using old (I'm guessing IPD
v2.x), unssupported software?

You don't need a backchannel (hardly anyone does). Even if you needed
can also deploy attribute queries (which you don't need either) using
the normal HTTPS port tcp/443. But let's ignore all that for now.
Your issue is the SP not recieving attributes. Once you fix your IDP
misconfiguration with regards to the backchannel port is irrelevant.

Also, if you're running httpd as web server why would you proxy
tcp/443 through httpd but expose java directly to the network on port
8443? If you proxy why not proxy both the same way?
Then make httpd listen on 8443 and make it use the backchannel key
pair, not Tomcat.

> > *Q.* And all of this is simply a demo setup, since you seem to be
> > running the IDP and the SP all *AT>>* on the same box? Or what
> > else is this for?
> This is POC so that we could move the same approach in actual environment.

It seems to me you're using stale/unsupported software, and normally
there's no need to have an SP co-located on the IDP. And you don't
need httpd installed with Tomcat, unless you know it's needed, which
you don't say, of course.  There's also no need for a backchannel in
most deployments.
So you should not do anything similar in production.

> Please help me out on this, struggling since long at same point. as
> it seems I am almost there but due to lack of knowledge I am not
> able to think in required direction.

No, your setup is a mess, I think. You haven't even identified the
main issue here: Your IDP is not sending any attributes to the SP.
Otherwise the SP wouldn't perform queries.
Once you fix that your IDP will still be misconfigured for queries but
you won't notice it. I think you should still fix that
misconfiguration, but it's easier to just remove port 8443 from your
setup (Tomca Connector or httpd listener) and from your IDP metadata
(also from the copy the SP has).

-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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

anuptiwary
This post was updated on .
idp-process.logYes, you are correct Peter. The problem here is SP in not receiving any
attribute parameter sent by idp.
I have verified the information by accessing below url -
/http://localhost/Shibboleth.sso/Session/ where no attributes value(s)
found.
How to approach towards this? Kindly help me out.
...
I am currently using idp - v2.4.5 which generates idp.crt(Public Key)
idp.key(Private key) idp.jks while installation. Please suggest the version
if it is not supported.
Current SP Version is - V2.6.1.4

If required I can share you the configuration files. Uploaded idp.process.log for reference.



--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
Reply | Threaded
Open this post in threaded view
|

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

Peter Schober
* anuptiwary <[hidden email]> [2018-07-27 11:52]:
> Yes, you are correct Peter. The problem here is SP in not receiving any
> attribute parameter sent by idp.
> I have verified the information by accessing below url -
> /http://localhost/Shibboleth.sso/Session/ where no attributes value(s)
> found.
> How to approach towards this?

1. Use the documentation
2. Use your log files
3. Ask specific questions if you don't understand the documentation

First you'll have to make sure your IDP is sending attributes.
(Use the IDP log files to determine that, and the IDP documentation

> I am currently using idp - v2.4.5 which generates idp.crt(Public Key)
> idp.key(Private key) idp.jks while installation.

Yes, as expected. That's obsolete. For over two years now, I think.
You may as well start from scratch using current, supported software.

(IDP v3.4 is around the corner, with IDP v4.0 possibly following soon.)

> Please suggest the version if it is not supported.

If you can find the software to download and install it, you can also
find the clear statements everywhere that IDP v2 is old and unsupported.
(For over two years now, I think.)

Deploying an SSO system (like other security software) is a highly
technical endeavor.  Being able to find the documentation and
statements about what versions/releases are supported is so low on the
scale of things required it hurts to spell this out:

https://wiki.shibboleth.net/confluence/display/IDP30/

-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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

anuptiwary
Thank you! for your response Peter.

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.

----idp-process.log---
16:18:27.873 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:473]
- Attribute principalId has 1 values after post-processing
16:18:27.873 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver:137]
- shibboleth.AttributeResolver resolved, for principal testuser, the
attributes: [principalId]
16:18:27.873 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:71]
- shibboleth.AttributeFilterEngine filtering 1 attributes for principal
testuser
16:18:27.874 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:130]
- Evaluating if filter policy releaseTransientIdToAnyone is active for
principal testuser
16:18:27.874 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:139]
- Filter policy releaseTransientIdToAnyone is active for principal testuser
16:18:27.874 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute transientId for principal
testuser
16:18:27.874 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:130]
- Evaluating if filter policy releaseUidToAnyone is active for principal
testuser
16:18:27.874 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:139]
- Filter policy releaseUidToAnyone is active for principal testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute uid for principal testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:130]
- Evaluating if filter policy releaseSnToAnyone is active for principal
testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:139]
- Filter policy releaseSnToAnyone is active for principal testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute sn for principal testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:130]
- Evaluating if filter policy releasePrincipalIdToAnyone is active for
principal testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:139]
- Filter policy releasePrincipalIdToAnyone is active for principal testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:163]
- Processing permit value rule for attribute principalId for principal
testuser
16:18:27.875 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109]
- Attribute principalId has 1 values after filtering
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]
16:18:27.877 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:505]
- Creating attribute statement in response to SAML request
'_28da556246a0427a1c89025c5225b37d' from relying party
'http://localhost:8080/WebUI'
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
16:18:27.881 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:528]
- Filtering out potential name identifier attributes which can not be
encoded by
edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:18:27.882 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:542]
- Retaining attribute principalId which may be encoded to via
edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:18:27.882 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:691]
- Selecting attribute to be encoded as a name identifier by encoder of type
edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:18:27.882 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:718]
- Selecting the first attribute that can be encoded in to a name identifier
16:18:27.882 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:502]
- Name identifier for relying party 'http://localhost:8080/WebUI' will be
built from attribute 'principalId'
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'
16:18:27.883 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:572]
- Determining if SAML assertion to relying party
'http://localhost:8080/WebUI' should be signed
16:18:27.883 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:653]
- IdP relying party configuration 'default' indicates to sign assertions:
true
16:18:27.883 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:583]
- Determining signing credntial for assertion to relying party
'http://localhost:8080/WebUI'
16:18:27.883 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:599]
- Signing assertion to relying party http://localhost:8080/WebUI
16:18:27.924 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:331]
- secondarily indexing user session by name identifier
16:18:27.924 - DEBUG
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:797]
- Encoding response to SAML request _28da556246a0427a1c89025c5225b37d from
relying party http://localhost:8080/WebUI
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,|




--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

Peter Schober
* anuptiwary <[hidden email]> [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
--
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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

Peter Schober
In reply to this post by anuptiwary
Forgot to comment on some of your statements:

* anuptiwary <[hidden email]> [2018-07-27 13:05]:
> As I can see in idp-process log. there is attribute principalId
> which is released by idp

No, your log states:

  "No attributes remained after encoding and filtering by value, no
  attribute statement built"

So no attributes have been released. From other log lines that's
because it has no encoder attached to it. So your resolver is likely
wrong.


> but seems my attribute-mapping or some other mapping does not hold
> true to pass it to SP.

That wouldn't make a missing attribute appear, but we also don't know
your attribute map.

> 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">

That's not how/where you map attributes. Also "sn" is not appropriate
as a unique identifier, and "NameID" probably doesn't exist, unless
you have created it in your attribute-map.xml.

-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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

anuptiwary
Please find attached attribute mapping xml(s)

- attribute-resolver.xml ( attribute-resolver.xml
<http://shibboleth.1660669.n2.nabble.com/file/t398706/attribute-resolver.xml>
)
- attribute-filter.xml ( attribute-filter.xml
<http://shibboleth.1660669.n2.nabble.com/file/t398706/attribute-filter.xml>
)
- attribute-map.xml ( attribute-map.xml
<http://shibboleth.1660669.n2.nabble.com/file/t398706/attribute-map.xml>  )

*Can you please help me here*, as per my understanding I have mapped
required entry.
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.




--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

Peter Schober
* anuptiwary <[hidden email]> [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
--
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: supplied TrustEngine failed to validate SSL/TLS server certificate - while validating the saml response send by idp to SP

anuptiwary
Thank You! Peter for your valuable response.
Finally my issue got resolved.. as suggested it was attribute mapping issue.

I have injected below mapping in attribute-map.xml file along with your
suggested change.

<Attribute name="urn:mace:dir:attribute-def:uid" id="uid" />
<Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="uid" />



--
Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]