Unsolicited IDP: RelayState and target
Matt Woodson
I am trying to solve an issue we are having with Salesforce (SFDC) and
our Shibboleth Unsolicited IDP instance.
When a user goes to a protected URL within SFDC while they are not
authenticated, they get sent back to our IDP for authentication. After
authenticating through our JBoss container, they are then sent back to
SFDC, and the user will land at the home page inside of SFDC. They will
not be sent to the original protected URL.
When SFDC sends the user back to our IDP, they also send back post data
with a RelayState variable set to the originally requested protected
URL. I belive SFDC is trying to emulate an SP, but they aren't an
official SP.
From what I can tell here,
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO,
the target parameter can be passed in along with the entityID to emulate
the RelayState.
Can I configured Unsolicited SSO to use the RelayState? Looking at the
headers, it appears that the RelayState data is lost through
authentication of my container. If it can't be used, can the target
parameter be configured to look at the RelayState post data?
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Chad La Joie
unsolicited SSO. Unsolicitied SSO is for when the SP isn't involved
with make the authentication request. The user just shows up with a
SAML response at the SP (hence the term, unsolicited).
The target parameter is the relay state. If the container is
stripping out information from the URL you'll need to contact the
container vendor and ask them how to stop that behavior. It has
nothing to do with the IdP which simple gets the HTTP request and asks
for the params.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Cantor, Scott
> with a RelayState variable set to the originally requested protected
> URL. I belive SFDC is trying to emulate an SP, but they aren't an
> official SP.
We don't support non-standard requests. The only things we support for SAML 2 are standard requests, or the unsolicited trigger protocol that was modeled on the old 1.x request profile. Most broken SPs that can't generate standard requests can be told to issue redirects with some parameters that will allow that endpoint to be used, but if they don't allow control over the parameters, then it won't work.
> From what I can tell here,
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO,
> the target parameter can be passed in along with the entityID to emulate
> the RelayState.
Yes, to match the old protocol. RelayState is a SAML parameter name and it's less confusing (to me) to avoid using SAML binding conventions when inventing a non-SAML protocol.
> Can I configured Unsolicited SSO to use the RelayState?
Not without plugging a custom MessageDecoder in. The UnsolictedSSO endpoint was coded to allow the protocol to be essentially replaced separately from the handler itself by plugging in a different decoder.
> Looking at the
> headers, it appears that the RelayState data is lost through
> authentication of my container. If it can't be used, can the target
> parameter be configured to look at the RelayState post data?
The target parameter is "target", period. It also isn't necessarily the case that you can read POST body parameters in a GET at all. That would be up to the container.
-- Scott
WULMS Alexander
Salesforce properly implements SAML v2 SP-initiated flow and also supports IdP-initiated flow.
Salesforce puts the relative URL to the requested page in the relaystate parameter. When you use the IdPUnsolicitedSSO handler on Shibboleth IdP, then you can indeed specify a value for the relaystate parameter. Though, keep in mind that you should URL-encode the relative URL when building your request string, especially if it contains special parameters or a query string.
Example to send a user to page /home/home2.jsp, on Salesforce my-domain your-organization.my.salesforc.com:
This is under the assumption that you have set-up an own sub-domain, using their my-domain feature and that the entity-id for that sub-domain is https://your-organization.my.salesforce.com:
It works. At least for us (with Shibboleth IdP 2.3.5).
See Salesforce documentation and help pages for further details on their SAML support.
Thanks and brs,
Alex
Matt Woodson
> Hi,
>
> Salesforce properly implements SAML v2 SP-initiated flow and also supports IdP-initiated flow.
>
> Salesforce puts the relative URL to the requested page in the relaystate parameter. When you use the IdPUnsolicitedSSO handler on Shibboleth IdP, then you can indeed specify a value for the relaystate parameter. Though, keep in mind that you should URL-encode the relative URL when building your request string, especially if it contains special parameters or a query string.
>
> Example to send a user to page /home/home2.jsp, on Salesforce my-domain your-organization.my.salesforc.com:
>
> https://your-idp-host/idp/profile/SAML2/Unsolicited/SSO?providerId=https%3A%2F%2Fyour-organization.my.salesforce.com&target=%2Fhome%2Fhome2.jsp
>
> This is under the assumption that you have set-up an own sub-domain, using their my-domain feature and that the entity-id for that sub-domain is https://your-organization.my.salesforce.com:
>
> It works. At least for us (with Shibboleth IdP 2.3.5).
Alex,
Thanks for the reply.
Getting the replaystate into the Unsolicited url as the "target"
parameter is what I was originally asking help for. That's the magic I
don't have. And, according to replies, Unsolicited mode doesn't do
anything with that relaystate variable.
For future list readers, I will post this info.
After more investigation and enabling domains at salesforce.com, we are
going to use sp-initiated SAML with shibboleth as the IDP. Once this is
done, we can use the relaystate as it is meant to be.
I originally misunderstood the part that sfdc will do sp-initiated SAML
once you have domains enabled.
Brent Putman
On 2/17/12 2:14 PM, Matt Woodson wrote:
>
> Getting the replaystate into the Unsolicited url as the "target"
> parameter is what I was originally asking help for. That's the magic I
> don't have. And, according to replies, Unsolicited mode doesn't do
> anything with that relaystate variable.
>
Well, a SAML IdP doesn't "do anything" with the RelayState, whether it's
a solicited SSO (SP-initiated) or unsolicited. This is by definition
from the SAML standard. The RelayState is a bit of data that the SP is
asking to be returned to it unmodified by the IdP when the user is sent
back to the SP. So the IdP's job is to just faithfully reflect it back
to the SP exactly as it was received. The only entity that actually
looks at that data and does something with it is the SP.
With unsolicited, you're just assuming (as the IdP admin) some knowledge
of what the SP would do with that data, and including an appropriate
value (or not, if none is needed)
>
> After more investigation and enabling domains at salesforce.com, we are
> going to use sp-initiated SAML with shibboleth as the IDP. Once this is
> done, we can use the relaystate as it is meant to be.
So switching from unsolicited to solicited is not going to change what
the SP does or does not do with the RelayState data. If you do
unsolicited (IdP initiated), and stick in RelayState value equal to what
the SP otherwise would have sent if you had done SP-initiated, the
result should be the same.