Hello,
We’re on CMS 1.8.7 and running into an issue where we are able to get the login page from the IdP but after successfully logging in, get the error message that no attributes could be mapped.
Followed the instructions on https://xibo.org.uk/manual/en/users_saml.html but want to confirm that the variable $samlSettings has changed to $settings with the workflow array going in the vendor\onelogin\php-saml\settings.php file? I’m not too familiar with php so apologies in advance.
We’ve kept the workflow variable as is and had our IdP admin provide UserName and email for mapping but didn’t work. We also had our IdP admin map using uid and mail but that didn’t work either.
$settings = array (
'workflow' => array(
// Enable/Disable Just-In-Time provisioning
'jit' => true,
// Attribute to identify the user
'field_to_identify' => 'UserName', // Alternatives: UserID, UserName or email
// Default libraryQuota assigned to the created user by JIT
'libraryQuota' => 1000,
// Initial User Group
'group' => 'Users',
// Home Page
'homePage' => 'dashboard',
// Enable/Disable Single Logout
'slo' => true,
// Attribute mapping between XIBO-CMS and the IdP
'mapping' => array (
'UserID' => '',
'usertypeid' => '',
'UserName' => 'uid',
'email' => 'mail',
'ref1' => '',
'ref2' => '',
'ref3' => '',
'ref4' => '',
'ref5' => ''
)
),
// If 'strict' is True, then the PHP Toolkit will reject unsigned
// or unencrypted messages if it expects them signed or encrypted
// Also will reject the messages if not strictly follow the SAML
// standard: Destination, NameId, Conditions ... are validated too.
'strict' => true,
// Enable debug mode (to print errors)
'debug' => true,
// Set a BaseURL to be used instead of try to guess
// the BaseURL of the view that process the SAML Message.
// Ex. http://sp.example.com/
// http://example.com/sp/
'baseurl' => null,
// Service Provider Data that we are deploying
'sp' => array (
// Identifier of the SP entity (must be a URI)
'entityId' => 'https://localhost/saml/metadata',
// Specifies info about where and how the <AuthnResponse> message MUST be
// returned to the requester, in this case our SP.
'assertionConsumerService' => array (
// URL Location where the <Response> from the IdP will be returned
'url' => 'https://localhost/saml/acs',
// SAML protocol binding to be used when returning the <Response>
// message. Onelogin Toolkit supports for this endpoint the
// HTTP-Redirect binding only
'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
),
// If you need to specify requested attributes, set a
// attributeConsumingService. nameFormat, attributeValue and
// friendlyName can be omitted. Otherwise remove this section.
//"attributeConsumingService"=> array(
// "ServiceName" => "SP test",
// "serviceDescription" => "Test Service",
// "requestedAttributes" => array(
// array(
// "name" => "",
// "isRequired" => false,
// "nameFormat" => "",
// "friendlyName" => "",
// "attributeValue" => ""
// )
// )
//),
// Specifies info about where and how the <Logout Response> message MUST be
// returned to the requester, in this case our SP.
'singleLogoutService' => array (
// URL Location where the <Response> from the IdP will be returned
'url' => 'https://localhost/saml/sls',
// SAML protocol binding to be used when returning the <Response>
// message. Onelogin Toolkit supports for this endpoint the
// HTTP-Redirect binding only
'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
),
// Specifies constraints on the name identifier to be used to
// represent the requested subject.
// Take a look on lib/Saml2/Constants.php to see the NameIdFormat supported
'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress',
// Usually x509cert and privateKey of the SP are provided by files placed at
// the certs folder. But we can also provide them with the following parameters
'x509cert' => '',
'privateKey' => '',
/*
* Key rollover
* If you plan to update the SP x509cert and privateKey
* you can define here the new x509cert and it will be
* published on the SP metadata so Identity Providers can
* read them and get ready for rollover.
*/
// 'x509certNew' => '',
),
// Identity Provider Data that we want connect with our SP
'idp' => array (
// Identifier of the IdP entity (must be a URI)
'entityId' => 'http://removed',
// SSO endpoint info of the IdP. (Authentication Request protocol)
'singleSignOnService' => array (
// URL Target of the IdP where the SP will send the Authentication Request Message
'url' => 'https://removed/sso/saml',
// SAML protocol binding to be used when returning the <Response>
// message. Onelogin Toolkit supports for this endpoint the
// HTTP-POST binding only
'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
),
// SLO endpoint info of the IdP.
'singleLogoutService' => array (
// URL Location of the IdP where the SP will send the SLO Request
'url' => 'https://removed/sso/saml',
// SAML protocol binding to be used when returning the <Response>
// message. Onelogin Toolkit supports for this endpoint the
// HTTP-Redirect binding only
'binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
),
// Public x509 certificate of the IdP
'x509cert' => 'removed',
/*
* Instead of use the whole x509cert you can use a fingerprint
* (openssl x509 -noout -fingerprint -in "idp.crt" to generate it,
* or add for example the -sha256 , -sha384 or -sha512 parameter)
*
* If a fingerprint is provided, then the certFingerprintAlgorithm is required in order to
* let the toolkit know which Algorithm was used. Possible values: sha1, sha256, sha384 or sha512
* 'sha1' is the default value.
*/
// 'certFingerprint' => '',
// 'certFingerprintAlgorithm' => 'sha1',
/* In some scenarios the IdP uses different certificates for
* signing/encryption, or is under key rollover phase and more
* than one certificate is published on IdP metadata.
* In order to handle that the toolkit offers that parameter.
* (when used, 'x509cert' and 'certFingerprint' values are
* ignored).
*/
// 'x509certMulti' => array(
// 'signing' => array(
// 0 => '<cert1-string>',
// ),
// 'encryption' => array(
// 0 => '<cert2-string>',
// )
// ),
),
);
Under Settings -> Troubleshooting tab we have the Log Level set to Debug and Server Mode to Test. But after going through the login process and getting the error, when going to Advanced -> Logs there are only a couple of errors from a month ago regarding some players.
It’s probably something very simple but not sure how to get this working. Any assistance would be greatly appreciated. Thanks!
