In the RelayState an SP may keep state about which resource a user
agent accessed (or tried to access) before sending them off to an IdP
(or discovery service). So RelayState is set by the SP and only means
something to the SP. How could the IdP then send a RelayState
parameter in an IdP-first flow?
-peter
-peter
--
You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
To post to this group, send email to simple...@googlegroups.com.
To unsubscribe from this group, send email to simplesamlph...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simplesamlphp?hl=en.
What is this "this", you want to achieve?
There is no RelayState (i.e., the user agent has no state at the
Service Provider) when you start at the IdP (i.e., IdP-initiated).
The SP decides where to route users to, after processing the SAML
assertion from the IdP.
-peter
-peter
The RelayState option that you can configure in a simpleSAMLphp SP is
only present as a default URL to use when the IdP does not include a
RelayState option in its response. But it is not relevant for your
case, since you are running an IdP.
> Can someone put some light on how to achieve this...
For information about how to to trigger IdP initiated SSO (with a
specific RelayState), see the documentation:
http://simplesamlphp.org/docs/1.8/simplesamlphp-idp-more#section_4
Best regards,
Olav Morken
UNINETT / Feide
I do not think this is a real format for a NameID? You should probably
set it to "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", to
match the example they have provided.
> 'simplesaml.nameidattribute' => 'uid',
> 'simplesaml.attributes' => FALSE,
> Will this pass the username correctly to successfactors???
It should, if "uid" is available at that point. I suggest that you take
a look at the response your IdP sends. You can do that by setting
'logging.level' to LOG_DEBUG, and enabling the 'debug' option in
config.php. That should ensure that the complete response sent to the SP
is logged in the log files.
Did you also adjust the log level?
> Feb 3 07:11:15 saml simplesamlphp[2665]: 6 [6bf0bcc38b] SAML2.0 -
> IdP.SSOService: Accessing SAML 2.0 IdP endpoint SSOService
> Feb 3 07:11:15 saml simplesamlphp[2665]: 6 [6bf0bcc38b] SAML2.0 -
> IdP.SSOService: IdP initiated authentication: 'successfactors.com'
> Feb 3 07:11:37 saml simplesamlphp[14657]: 5 STAT [6bf0bcc38b]
> saml20-idp-SSO-first successfactors.com
> http://saml.client.com/simplesaml/saml2/idp/metadata.php NA
> Feb 3 07:11:37 saml simplesamlphp[14657]: 5 STAT [6bf0bcc38b]
> saml20-idp-SSO successfactors.com
> http://saml.client.com/simplesaml/saml2/idp/metadata.php NA
> Feb 3 07:11:37 saml simplesamlphp[14657]: 6 [6bf0bcc38b] Sending SAML 2.0
> Response to 'successfactors.com'
>
> Also how do set the Relay State paramater in the Idp First-flow... what is
> urn and someservice mentioned in this example mean.
>
>
> https://idp.example.org/simplesaml/saml2/idp/SSOService.php?spentityid=urn:mace:feide.no:someservice&RelayState=https://sp.example.org/somepage
>
>
>
> My url would look like this...
>
> https://saml.client.com/simplesaml/saml2/idp/SSOService.php?spentityid=urn:successfactors.com:someservice&RelayState=https://succesfactors.com/login
The "spentityid" parameter specifies the SP entityID. This appears to
be "successfactors.com" for you, based on the log you pasted.
The value of the RelayState depends on what your SP expects. It _may_
be an URL, but it can also be something else, or nothing at all. It is
up to the SP software to decide what value it wants to be passed in the
RelayState parameter.
Maybe your syslog configuration is set up to store debug information in
a different file or to not log it at all?
As you have seen, the username is sent as the name identifier in the
response. It appears to be a valid SAML 2.0 response. There isn't really
very much else to say about it.
If your SP has specific requirements for the response, you should check
it against those requirements.
> Also, I have sent them the issuer as
> http://saml.client.com/simplesaml/saml2/idp/metadata.php is this correct?.
It depends on your configuration. It is correct in the default
configuration.
> :19:04 saml simplesamlphp[2665]: 6 [ab4d77ad3f] SAML2.0 - IdP.SSOService:
> Accessing SAML 2.0 IdP endpoint SSOService
> :19:04 saml simplesamlphp[2665]: 6 [ab4d77ad3f] SAML2.0 - IdP.SSOService:
> Accessing SAML 2.0 IdP endpoint SSOService
You appear to have something strange in your configuration, since
everything is logged twice.
[...]
> :19:04 saml simplesamlphp[2665]: 3 [ab4d77ad3f] Caused by: Exception:
> Unable to find the current binding.
The IdP was unable to determine the "binding" used when accessing the
SSOService endpoint. Probably a missing query parameter or something
like that.
This parameter is ignored for saml20-idp-hosted.
> 'authority' => 'login'
This one isn't used for IdPs configured with config/authsources.php.
> Do you see any issues with the configuration...
I'm not about to read through your entire configuration without
looking for a specific error :)
Are you experiencing any specific errors?
As in "SAML 2.0 binding", the method that is used to transport SAML 2.0
messages over various channels. See:
http://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
> Missing query parameter??
I should maybe have said "request parameter" here, as it is more
generic than "query parameter". The code that determines the current
binding looks at the request method and the request parameters to make
an educated guess as to which SAML 2.0 binding was used to send the
message.
(To support IdP initiated SSO, the SSOService endpoint also looks for a
"spentityid" parameter as an alternative. That is not standardized, and
isn't a part of the normal SAML 2.0 bindings.)
> Any help... Is it at the Service
> Provider side or on Idp side...
That depends :)
For some reason your web browser ends up sending a request to the
SingleSignOnService endpoint that simpleSAMLphp is unable to determine
what to do about. The question is why the web browser ends up doing
that.
> I didn't change any configuration on my side, earlier i used to get the
> successfactors login page but now after the POST
After which POST? The login form? The HTTP-POST binding used to send
authentication responses from the IdP to the SP? Some other POST?
>, I get this error and not
> redirecting to the successfactors page...
I suggest you look at the requests your browser make, and try to
determine what page is sending you to the SingleSignOnService endpoint,
and why that page makes that decision. If you are using Firefox, you
may want to test the SAML tracer add-on:
https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/
This is an add-on that we developed that also decodes SAML 2.0 messages
sent through the browser.
POST http://saml.client.com/simplesaml/module.php/core/loginuserpass.php? HTTP/1.1
( Referer: http://saml.client.com/simplesaml/module.php/core/loginuserpass.php?AuthState=_2448c08a68f2d0e45c81441eeb3f73f57c137167f6%3Ahttp%3A%2F%2Fsaml.client.com%2Fsimplesaml%2Fsaml2%2Fidp%2FSSOService.php%3Fspentityid%3Dwww.successfactors.com%26cookieTime%3D1328930369
POST https://performancemanager4.successfactors.com/saml2/SAMLAssertionConsumer?company=clientTest HTTP/1.1
( Referer: http://saml.client.com/simplesaml/module.php/core/loginuserpass.php? )
GET http://saml.client.com/simplesaml/saml2/idp/SSOService.php HTTP/1.1( Referer: http://saml.client.com/simplesaml/module.php/core/loginuserpass.php? )--- Also, I see one of their requirement isThey currently require the AttributeStatement <saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"xmlns:xs="http://www.w3.org/2001/XMLSchema"><saml:Attribute Name="password"NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:type="xs:string"> lhadley</saml:AttributeValue></saml:Attribute></saml:AttributeStatement>How to specify this in sp-remote.php------------------------------------------------Settings provided by Successfactors :-------------------------------------------------SuccessFactors Entity ID
https://www.successfactors.com <https://www.successfactors.com>
SuccessFactors Certificate for Optional Encryption of Assertion. Sent as separate attachment SFAdmin.txt
Consumer Service URL
https://performancemanager4.successfactors.com/saml2/SAMLAssertionConsumer?company=clientTest
Optional Global Logout Response Handler URL
https://performancemanager4.successfactors.com/saml2/LogoutServiceHTTPRedirectResponse?company=clientTest
RelayState
monitor is configured for Ultra
https://performancemanager4.successfactors.com/xi/ui/home/pages/home.xhtml
Chetan Jain.Chetan Jain
[...]
> *POST https://performancemanager4.successfactors.com/saml2/SAMLAssertionConsumer?company=clientTest
> HTTP/1.1*
[...]
> *GET http://saml.client.com/simplesaml/saml2/idp/SSOService.php HTTP/1.1*
So, the SP redirects back to the IdP after receiving an authentication
response. You need to find out why it does that, as that is not part of
the normal IdP-initiated authentication flow.
> *--- Also, I see one of their requirement is *
>
>
> They currently
> require the AttributeStatement
> <saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
> <saml:Attribute
> Name="password"
Hmmm.. The SP required to receive the user's password as an attribute?
Not supported directly by simpleSAMLphp. Depending on the
authentication source you are using, you may be able to add it to the
attributes that are sent, but it looks rather strange to me.
Including it in the link is the normal way to do it when you are using
IdP initiated authentication.