[Shib-Users] Shibboleth.sso/SAML/POST redirect?

[B.E.N. van der Veen]

Everything works fine....so it seems. Login good. SAML encoding fine.

15:54:11.535 - DEBUG
[org.opensaml.ws.message.encoder.BaseMessageEncoder:54] - Successfully
encoded message.
15:54:11.536 - INFO [Shibboleth-Audit:695] -
20110423T135411Z|urn:mace:shibboleth:1.0:profiles:AuthnRequest||urn:sitefromme|urn:mace:shibboleth:2.0:profiles:saml1:sso|https://idpdns/default|urn:oasis:names:tc:SAML:1.0:profiles:browser-post|_db63d91dbdda3ccf4c8e378fa159e442|shibboleth|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||_d43267b0b689600973dcb8ec0fae0ff8|_aad4132ec88d81252ec7c985bd0e13ec,|

But then it redirects me to: https://spdns/Shibboleth.sso/SAML/POST ????
I want to go to https://spdns/secure/index.html

Who knows what is happening?

Cheerz
Ben

[Nate Klingenstein]

Ben,

This is expected behavior.  The user is first sent to the assertion consumer service, located at Shibboleth.sso/SAML/POST for SAML 1.1 messages.  The assertion is processed there, and then the user is redirected to their requested resource with Shibboleth header/environment variables set and a session established.

Is there a reason you think something is wrong?

Thanks,

Nate.

[B.E.N. van der Veen]

Hello Nate,

I am expecting the user to be redirected to the page he wanted to get
acces to. For example:

1. User goes to: https://myurl/secure [and then the index.html]
2. He is redirected to the IDP by the SP
3. He uses the authenticationprotocol i set in the IDP for the SP
4. User is logged in correctly and also has the right to go to the URL
https://myurl/secure
5. He expect to get on the right URL = https://myurl/secure , but
instead he get to https://myurl/secure/Shibboleth.sso/Shibboleth/SSO <--
I changed the SAML/POST to Shibbolth/SSO

That's why I think it is wrong ;-))

Cheerz
Ben

Nate Klingenstein schreef:

[Nate Klingenstein]

Ben,

Everything you describe is similar to the default flows, except that you don't include the initial landing at the assertion consumer service, nor the redirect from there to the application.  It's a step common to a lot of SSO flows, including Shibboleth, and it will work fine unless you modified something.

This detailed discussion of a typical SAML 1.1 flow in Shibboleth should be useful for your understanding:

http://www.switch.ch/aai/demo/expert.html

Also, I'll channel Scott here and say you shouldn't make changes to the configuration unless you fully understand the implications.  You can modify the handler locations, but they will need to match your SP's metadata as loaded by your IdP.  In general, there's no need to do this, and the defaults are good.

Let us know how we can help,

Nate.

[B.E.N. van der Veen]

Hello Nate,

Yes so close ;-)) First I will fill you with some logging and the definition of my Assertion Consumer Services (conform ProfileHandlers in the handler.xml) and the key/certificate information I flushed from the logging. I do not think the problem is in the handshaking from certificates.

In the idp-metadata.xml [Put on the SP server]
<md:SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://dnsfromidp/idp/profile/Shibboleth/SSO"/>  in the idp-metadata.xml

In the sp-metadata.xml [Put on the IDP server]
    <md:AssertionConsumerService Location="/Shibboleth.sso/Shibboleth/SSO" index="1"
      Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>
    <md:AssertionConsumerService Location="/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
    <md:AssertionConsumerService Location="http://www.time-less.nl/Drupal" index="3"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
    <md:AssertionConsumerService Location="/Shibboleth.sso/SAML2/SOAP/AttributeQuery" index="4"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
    <md:AssertionConsumerService Location="/Shibboleth.sso/SAML2/SOAP/ArtifactResolution" index="5"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
    <md:AssertionConsumerService Location="/Shibboleth.sso/SAML2/POST/SSO" index="6"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>

Marshalled message into DOM:
<?xml version="1.0" encoding="UTF-8"?><saml1p:Response xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2011-04-23T15:48:48.088Z" MajorVersion="1" MinorVersion="1" Recipient="https://dnsfromsp/Shibboleth.sso/Shibboleth/SSO" ResponseID="_bdf2240670030300805516d157640fb7"><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#_bdf2240670030300805516d157640fb7"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>7X0WB8I/SVb4i0smpdg1Nbsl4Bc=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>
</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml1p:Status><saml1p:StatusCode Value="saml1p:Success"/></saml1p:Status><saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_44c28d01392a1b9a46df35e71d24f191" IssueInstant="2011-04-23T15:48:48.088Z" Issuer="urn:time-less.nl:sp1" MajorVersion="1" MinorVersion="1"><saml1:Conditions NotBefore="2011-04-23T15:48:48.088Z" NotOnOrAfter="2011-04-23T15:53:48.088Z"><saml1:AudienceRestrictionCondition><saml1:Audience>urn:time-less.nl:sp1</saml1:Audience></saml1:AudienceRestrictionCondition></saml1:Conditions><saml1:AuthenticationStatement AuthenticationInstant="2011-04-23T15:48:48.045Z" AuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"><saml1:Subject><saml1:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="urn:time-less.nl:sp1">_bef534b46000a7af09dd0e1e55298147</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml1:ConfirmationMethod></saml1:SubjectConfirmation></saml1:Subject><saml1:SubjectLocality IPAddress="192.168.1.100"/></saml1:AuthenticationStatement></saml1:Assertion></saml1p:Response>
17:48:48.334 - DEBUG [org.opensaml.saml1.binding.encoding.HTTPPostEncoder:135] - Setting TARGET parameter to: cookie:d62cae72
17:48:48.357 - DEBUG [PROTOCOL_MESSAGE:64] -
<?xml version="1.0" encoding="UTF-8"?><saml1p:Response xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2011-04-23T15:48:48.088Z" MajorVersion="1" MinorVersion="1" Recipient="https://dnsfromsp/Shibboleth.sso/Shibboleth/SSO" ResponseID="_bdf2240670030300805516d157640fb7">
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
         <ds:Reference URI="#_bdf2240670030300805516d157640fb7">
            <ds:Transforms>
               <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
               <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>7X0WB8I/SVb4i0smpdg1Nbsl4Bc=</ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue></ds:SignatureValue>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate></ds:X509Certificate>
         </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
   <saml1p:Status>
      <saml1p:StatusCode Value="saml1p:Success"/>
   </saml1p:Status>
   <saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_44c28d01392a1b9a46df35e71d24f191" IssueInstant="2011-04-23T15:48:48.088Z" Issuer="urn:time-less.nl:sp1" MajorVersion="1" MinorVersion="1">
      <saml1:Conditions NotBefore="2011-04-23T15:48:48.088Z" NotOnOrAfter="2011-04-23T15:53:48.088Z">
         <saml1:AudienceRestrictionCondition>
            <saml1:Audience>urn:time-less.nl:sp1</saml1:Audience>
         </saml1:AudienceRestrictionCondition>
      </saml1:Conditions>
      <saml1:AuthenticationStatement AuthenticationInstant="2011-04-23T15:48:48.045Z" AuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
         <saml1:Subject>
            <saml1:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="urn:time-less.nl:sp1">_bef534b46000a7af09dd0e1e55298147</saml1:NameIdentifier>
            <saml1:SubjectConfirmation>
               <saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</saml1:ConfirmationMethod>
            </saml1:SubjectConfirmation>
         </saml1:Subject>
         <saml1:SubjectLocality IPAddress="192.168.1.100"/>
      </saml1:AuthenticationStatement>
   </saml1:Assertion>
</saml1p:Response>

17:48:48.357 - DEBUG [org.opensaml.ws.message.encoder.BaseMessageEncoder:54] - Successfully encoded message.
17:48:48.360 - INFO [Shibboleth-Audit:695] - 20110423T154848Z|urn:mace:shibboleth:1.0:profiles:AuthnRequest||urn:time-less.nl:sp1|urn:mace:shibboleth:2.0:profiles:saml1:sso|urn:time-less.nl:sp1|urn:oasis:names:tc:
SAML:1.0:profiles:browser-post|_bdf2240670030300805516d157640fb7|shibboleth|urn:oasis:names:tc:SAML:2.0:ac:classes:
PasswordProtectedTransport||_bef534b46000a7af09dd0e1e55298147|_44c28d01392a1b9a46df35e71d24f191,|

Cheerz
Ben

Nate Klingenstein schreef:

Ben,

[Cantor, Scott E.]

> Yes so close ;-)) First I will fill you with some logging and the definition of my
> Assertion Consumer Services (conform ProfileHandlers in the handler.xml)

No, they don't. handler.xml is an IdP configuration file, and ACS endpoints are an SP issue.

> and the key/certificate information I flushed from the logging. I do not think
> the problem is in the handshaking from certificates.

Your problem is undoubtedly what Nate indicated, you've changed settings that don't need to be changed.

-- Scott

[B.E.N. van der Veen]

I will try to find what I did wrong. If I install everything from
scratch then I will never understand the main concept.

Cheerz
Ben

Cantor, Scott E. schreef:

[B.E.N. van der Veen]

Hi Scott,

_I did not changes the settings other than the:_
- metadata.xml (for SP and IDP seperate...yes this I changed)
- handler.xml (i did not change!)
- relying-party.xml (yes this I changed)
- shibboleth2.xml (yes this I changed on SP side [IDP side does not have
one])
- atrribute-resolver.xml (i did not change)

So where do i have to look at....metadata's or shibboleth2.xml.......but
where. My guts say it must be easy, but I keep looking at the same
things and don't seem te see it..

Cheerz
Ben

Cantor, Scott E. schreef:

[B.E.N. van der Veen]

Hi Nate/Scott,

Another answer from me. I put every configuration back and followed the
URL Nate gave me. I Also get a SAML2 respons. No problem so it looks
like. But than it redirects me to
https://dnsfromsp/Shibboleth.sso/SAML2/POST/SSO but I expact it to go to
https://dnsfromsp/secure/index.html [where a test page stands and where
the user initial went to]

I suspect it is something in my metadata, but where do I have to search
for??

Cheerz
Ben

Cantor, Scott E. schreef:

[Cantor, Scott E.]

On Apr 24, 2011, at 7:21 AM, "B.E.N. van der Veen" <bvd...@time-less.nl> wrote:
> Another answer from me. I put every configuration back and followed the URL Nate gave me. I Also get a SAML2 respons. No problem so it looks like. But than it redirects me to https://dnsfromsp/Shibboleth.sso/SAML2/POST/SSO but I expact it to go to https://dnsfromsp/secure/index.html [where a test page stands and where the user initial went to]

It MUST send you to that location, that's where the SAML response is processed. If that succeeds, it will redirect you to wherever the relay state information tells it to. If it fails, it will report an error.

It will not, can not, and does not ever skip the URL you seem obsessed with avoiding.

-- Scott

[Peter Schober]

* B.E.N. van der Veen <bvd...@time-less.nl> [2011-04-24 13:22]:

> But than it redirects me to
> https://dnsfromsp/Shibboleth.sso/SAML2/POST/SSO but I expact it to go to
> https://dnsfromsp/secure/index.html

Then you're still suffering from self-inflicted problems by randomly
changing stuff. If your IdP sends you to an ACS URL ending in
/Shibboleth.sso/SAML2/POST/SSO the metadata the IdP has for your SP is
wrong, as no such endpoint exists at the SP.

I won't comment on your "but I want to go to /secure/" since this has
been explained to you twice already. If the above errors wouldn't
prevent the SAML flow from working, you'd end up at the desired URL.
-peter

[B.E.N. van der Veen]

Problem solved!

The solution for me was: in IIS with the extension .sso i had enabled
"check if file exists". That's why i did not recieve the correct error
and logging. After unchecking this option I saw that my certificates
where not correct. After changing this everything works like a charm!

Thanks you all.

Cheerz
Ben

Peter Schober schreef:

[B.E.N. van der Veen]

After having Shibboleth up and running you see the next challenge ;-)) I
have my SP on a different machine than my IDP. This with reason. The SP
must be in the DMZ and the SP talks inside to the IDP. But after
checking the IDP also talks to the user (internet). This to give the
user the possibility to login with a username and password.

So what to do next? IDP and SP on one machine and placing it in the DMZ?
Or using a reversed proxy?

[Nate Klingenstein]

Ben,

If you're using SAML 2.0 and standard HTTP POST flows, there's
generally no need for the IdP and the SP to be able to directly
communicate with each other. All communication is done through the
user agent. You'll be unable to use protocols that rely on direct
bindings, such as attribute queries, artifact resolution and some
forms of single logout. Most deployments will be okay with this.

Regardless, the user agent will need to be able to communicate with
both. You'll still need some way to exchange metadata, too, which can
be done through any method of your choice(e.g. out of band).

Glad you got it working,
Nate.

[B.E.N. van der Veen]

Hello Nate,

I find the activity and support on this product very good. Very
important to have an active community. If I can contribute in some
matter I will participate.

The problem is on the internet the IDP and SP have their own DNS. This
is because they are on sepperate machines. My testlab only has one
public IP. So the firewall can't determine where to go to. One public IP
is also critical cause this is the whole point of indentifying ;-))

I read about Squid and reverse proxy....maybe this is the way to go. I
use SAML 2.0 and HTTP POST (ssl) so this is not the problem.

Cheerz
Ben

Nate Klingenstein schreef:

[Peter Schober]

* B.E.N. van der Veen <bvd...@time-less.nl> [2011-04-25 10:58]:

> The problem is on the internet the IDP and SP have their own DNS. This
> is because they are on sepperate machines. My testlab only has one
> public IP. So the firewall can't determine where to go to. One public IP
> is also critical cause this is the whole point of indentifying ;-))

Shibboleth doesn't care about IP adresses, for the most part.
Each component (IdP, SP) can have its own hostname (on the same
machine or on different machines) or they can just as well be on the
same (v)host.
So there are no requirements whatsoever with regrad to firewalls,
DMZs, DNS or anything else from Shibboleth. While you might have such
constraints from your network or test lab setup, this is nothing
anyone here can help you with and, again, Shibboleth doesn't change
or introduce anything new here.
-peter

[B.E.N. van der Veen]

Hello Peter,

I must be seeing things then:

In my metadatafiles:

<md:AssertionConsumerService
Location="https://dnsfromsp/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"

Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>

<md:SingleSignOnService

Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

Location="https://dnsfromidp/idp/profile/SAML2/POST/SSO"/>

So there is definitly a direction to a machine [IDP and SP]. Where the
metadata tells where to find what.

I do not know what you are suggesting.....

Cheerz
Ben

Peter Schober schreef:

[Peter Schober]

* B.E.N. van der Veen <bvd...@time-less.nl> [2011-04-25 14:29]:

> I must be seeing things then:

I guess you are.

> In my metadatafiles:
>
> <md:AssertionConsumerService
> Location="https://dnsfromsp/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>

This has nothing to do with anything in this thread. Or your error,
for that matter.

> <md:SingleSignOnService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Location="https://dnsfromidp/idp/profile/SAML2/POST/SSO"/>
>
> So there is definitly a direction to a machine [IDP and SP]. Where
> the metadata tells where to find what.

I have no idea what you're talking about and what the above should

indicate or prove. You wrote:

* B.E.N. van der Veen <bvd...@time-less.nl> [2011-04-24 13:22]:
> But than it redirects me to
> https://dnsfromsp/Shibboleth.sso/SAML2/POST/SSO

which is an invald endpoint at your SP, so an error is to be
expected.
Above you present a different (and completely unrelated) endpoint at
your SP (which might exist, but that's irrelevant) and present yet
another endpoint at the IdP -- which, again, is irrelevant.

If you get redirected to
"https://dnsfromsp/Shibboleth.sso/SAML2/POST/SSO" as you say, then
your IdP must have this URL somewhere in the metadata for the SP.
This is wrong, as, this endpoint does not exist and it does not make
any sense (SSO is a function of an IdP, so there cannot be an "SSO"
endpoint at an SP).
All of this still points to you changing random stuff and asking
questions about the effects on the list here.

What you should do:
* The SP can generate an approximation of its own metadata, check the
documentation on how and do this (a hint: access the URL
https://dnsfromsp/Shibboleth.sso/Metadata )
* Give this piece of metadata to your IdP (according to the
documentation for the IdP configuration) instead of any of the
existing metadata resources.
* If none of this helps post your IdP and SP metadata somewhere on the
net and provide a link here so that people can look at it.

If all else fails, start from scratch and follow the documentation to
the letter.
-peter

[B.E.N. van der Veen]

Hello Peter,

This explains a lot! Thank you for the critical answer. I will try al
the suggestions you have. I have everything up and running. But that it
is running does not say it is correct configured ;-))

Cheerz
Ben

Peter Schober schreef:

[BMWTouring]

This Thread can be closed. When reading the documentation on the site made it
more clear. But the reading made sense after posting the question and the
answers I got. Thank you for this.

Cheerz
Ben

--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Shibboleth-sso-SAML-POST-redirect-tp6299489p6307598.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.