Unsolicited IDP: RelayState and target

[Chad La Joie]

Well, if Salesforce is sending something to your IdP than it's not an
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.

On Mon, Feb 13, 2012 at 13:18, Matt Woodson <mwoodson at redhat.com> wrote:
> All,
>
> 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-unsubscribe at shibboleth.net



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered