Danish nemlogin, URL is malformed.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Danish nemlogin, URL is malformed.

Bo Lorentsen
Hi ...

Yesterday I was so happy, we manage to get shibboleth to successfully
send AuthRequests using sha256 signing, and it all seems so nice when we
got us self a nice valid assert response.

But today, we found that some users ends up with a shibboleth "URL is
malformed" page.

In desperation, I have turned up the debug level in the shibd.logger (I
am on debian linux), to see if something goes wrong, or if some mappings
misbehaved, but it all seems fine, even with all this nice debugging.

It seems like the mapping worked, no errors (a few missing values, in
both cases), it seems to store the session and then it redirects, here
is the log (changed a few minor things like urls)  :

2018-06-27 12:07:56 DEBUG XMLTooling.StorageService [2]: inserted record
(_035f6984-e305-4a4d-9f44-3d3e00f05a74) in context
(_99e7b5d183d11bdd686ebb9618e9d088) with expiration (1530104876)
2018-06-27 12:07:56 INFO Shibboleth.SessionCache [2]: new session
created: ID (_99e7b5d183d11bdd686ebb9618e9d088) IdP
(https://saml.nemlog-in.dk)
Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (213.32.247.234)
2018-06-27 12:07:56 DEBUG Shibboleth.SSO.SAML2 [2]: ACS returning via
redirect to: https%3A%2F%2Fxxx.example.io%2Fsso

So, it seems to me that we map the attributes (no conversion errors),
and store the session, and then redirects. But the problem that trigger
the error page, is not visible here, and I don't really know where to look.

Can anyone give me, as to where to look ?

/BL

Ps.: I have attached the assertion XML, where i removed sensitive or not
needed info, is anyone wonder :-)


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

ssi_assert_fmt.xml (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Danish nemlogin, URL is malformed.

Rod Widdowson
> Can anyone give me, as to where to look ?

Asking the obvious:

Nothing in the native log/syslogd or from apache?




--
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: Danish nemlogin, URL is malformed.

Bo Lorentsen
Nice point, I am not using apache but nginx, and the flow is ok but as
far as I can see the error is triggered inside shibboleth as the error
page is /Shibboleth.sso/SAML2/POST that is managed by it.

I hope this is attribute mapping related, but I really cant tell.

/BL


On 06/27/2018 03:58 PM, Rod Widdowson wrote:
>> Can anyone give me, as to where to look ?
> Asking the obvious:
>
> Nothing in the native log/syslogd or from apache?
>
>
>
>


--
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: Danish nemlogin, URL is malformed.

Cantor, Scott E.
On 6/27/18, 10:53 AM, "users on behalf of Bo Lorentsen" <[hidden email] on behalf of [hidden email]> wrote:

> I hope this is attribute mapping related, but I really cant tell.

It's not. The "malformed" language appears when it's sanitizing a URL and doesn’t find a colon in it at a point that one has to appear. It's probably an IdP not performing correct URL encoding somewhere or an application not doing it in the first place.

-- Scott


--
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: Danish nemlogin, URL is malformed.

Bo Lorentsen
On 06/27/2018 05:01 PM, Cantor, Scott wrote:
> On 6/27/18, 10:53 AM, "users on behalf of Bo Lorentsen" <[hidden email] on behalf of [hidden email]> wrote:
>
>> I hope this is attribute mapping related, but I really cant tell.
> It's not. The "malformed" language appears when it's sanitizing a URL and doesn’t find a colon in it at a point that one has to appear. It's probably an IdP not performing correct URL encoding somewhere or an application not doing it in the first place.
Now I think I (finally) understand what you meant. The idP returns me
the final redirection URL by setting the relayState in the result form
(found it in my browser), and the Nemlogin idP sends this in an URL
encoding shibboleth don't find valid as it does not expect it to be URL
encoded, and does not decode it either.

I can now verify this, by making an AuthRequest that result in the above
error, if i then reenter the original sso url (where the nginx auth
handler resides) the CGI on that location are then authorized and I log
in as expected.

I quess this is something I should take up with the idP :-)

I tried to fix this by using the applicationOverride attribute homeURL,
but I can't find a way to force shibboleth to use homeURL over
relayState, or have I missed something ?

/BL
>
> -- Scott
>
>


--
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: Danish nemlogin, URL is malformed.

Cantor, Scott E.
On 6/27/18, 1:05 PM, "Bo Lorentsen" <[hidden email]> wrote:

> Now I think I (finally) understand what you meant. The idP returns me
> the final redirection URL by setting the relayState in the result form
> (found it in my browser), and the Nemlogin idP sends this in an URL
> encoding shibboleth don't find valid as it does not expect it to be URL
> encoded, and does not decode it either.

No, it's already decoded, it's a parameter in the POST. If that's still encoded after that, then it was doubly-encoded to start with.

> I quess this is something I should take up with the idP :-)

Depends what issued it the request. If the RelayState is wrong in, it will be wrong out.

> I tried to fix this by using the applicationOverride attribute homeURL,
> but I can't find a way to force shibboleth to use homeURL over
> relayState, or have I missed something ?

If it believes the RelayState is a URL then that's what it's going to assume it should do. You can manipulate what the SP tries to do up front but not if it's not issuing the request to start with.

I didn't remember that the malformed language was so tightly scoped to that case. I think the message should be clearer given that it's apparently only happening in response to more or less that exact single issue.

-- Scott



--
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: Danish nemlogin, URL is malformed.

Bo Lorentsen
On 27-06-2018 19:18, Cantor, Scott wrote:
> On 6/27/18, 1:05 PM, "Bo Lorentsen" <[hidden email]> wrote:
>
>> Now I think I (finally) understand what you meant. The idP returns me
>> the final redirection URL by setting the relayState in the result form
>> (found it in my browser), and the Nemlogin idP sends this in an URL
>> encoding shibboleth don't find valid as it does not expect it to be URL
>> encoded, and does not decode it either.
> No, it's already decoded, it's a parameter in the POST. If that's still encoded after that, then it was doubly-encoded to start with.
Perfect, this is the problem, and also what I found in the log file, it
would have been nice if the log file gave an error along with the error
page.
>
>> I quess this is something I should take up with the idP :-)
> Depends what issued it the request. If the RelayState is wrong in, it will be wrong out.
Before nemlogin change to sha256, this worked fine, in the same setup,
so I guess they have changed a bit more than the signing alg.
>
>> I tried to fix this by using the applicationOverride attribute homeURL,
>> but I can't find a way to force shibboleth to use homeURL over
>> relayState, or have I missed something ?
> If it believes the RelayState is a URL then that's what it's going to assume it should do. You can manipulate what the SP tries to do up front but not if it's not issuing the request to start with.
I am not doing anything special, only what shibboleth is doing as
default (sending the current location url ... I quess).
> I didn't remember that the malformed language was so tightly scoped to that case. I think the message should be clearer given that it's apparently only happening in response to more or less that exact single issue.
That would have been helpful in this case, but on the other hand, this
error type is a bit rare.

I will let you know if the idP relayState encode fix, both is possible
and works, but now i know where to point :)

Anyway, thanks for all your valuable input guys, these kept me sane :-)

/BL

--
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: Danish nemlogin, URL is malformed.

Cantor, Scott E.
> I am not doing anything special, only what shibboleth is doing as default
> (sending the current location url ... I quess).

That is not the SP default, in the sense that it's not what the configuration as-shipped does, but I believe it's the default if the as-shipped relayState setting is not set due to having been removed. It's a code default but not an out of the box default. If that's what the SP is doing, then the IdP does have a bug.

-- Scott

--
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: Danish nemlogin, URL is malformed.

Bo Lorentsen
On 27-06-2018 21:01, Cantor, Scott wrote:
>> I am not doing anything special, only what shibboleth is doing as default
>> (sending the current location url ... I quess).
> That is not the SP default, in the sense that it's not what the configuration as-shipped does, but I believe it's the default if the as-shipped relayState setting is not set due to having been removed. It's a code default but not an out of the box default. If that's what the SP is doing, then the IdP does have a bug.
The default example config in debian has relayState="ss:mem" ... but the
doc say that we will fallback to relayState, if this is totally left out
(as You stated). I use an application override per domain I handle
(domain=idP), and none of there Sessions blocks have this relayState,
and will therefore will be normal idP relayState behavior (just to clarify).

You made med dive down in a few new things. I took a closer look into
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions ...

It seems like I could make one of these instead

<Sessions relayState="cookie" ...

or "ss:mem"

Both of these uses relayState as transportation, so quess what ... they
are both URL encoded on there return, by the idP :-(

So again ... back to the original plan, talk to idP (a large Danish
governmental cooperation .. )

/BL

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]