* Ryan Weiss <
rw3...@gmail.com> [2015-11-18 04:37]:
> First thing I tried was configuring the example-userpass authsource, like
> this:
[...]
> Caused by: Exception: Could not resolve 'exampleauth:UserPass': No class
> named 'sspmod_exampleauth_Auth_Source_UserPass'.
> So it's saying it can't find the'sspmod_exampleauth_Auth_Source_UserPass' class,
> however, this seems to exist just fine in the source code:
> /simplesamlphp/modules/exampleauth/lib/Auth/Source/UserPass.php
It's disabled by default:
$ ls modules/exampleauth/*able*
modules/exampleauth/default-disable
You need to enable it first:
$ touch modules/exampleauth/enable
I'm pretty sure the documentation covers usage of modules somewhere.
It's good we're actually going back to the very first steps of how to
use SimpleSAMLphp as at I couldn't follow all the weird things that
happend (or that you tried/caused). To me all that created the
impression that you knew what you were doing and that you're certain
the basic config is correct. Seems I was mistaken.
> 'drupalauth' => array(
> 'saml:SP',
> //is this correct? should be the SP entity ID as defined in saml20-sp-remote.php?
> 'entityID' => 'default-sp',
The comment above the auth source called 'default-sp' as shipped by
default in SimpleSAMLphp is:
// The entity ID of this SP.
If that isn't clear, there's always the documentation.
So yes, that's the SP's own entityID, but NOT "as defined in
saml20-sp-remote.php" because this here is the SP, and an SP does not
federate with other ("remote") SPs, so saml20-sp-remote.php is fully
irrelevant for an SP. The documentation for the SimpleSAMLphp SP also
never mentions saml20-sp-remote.php.
(A SimpleSAMLphp IDP would use saml20-sp-remote.php, though, and that
would contain your own SP as well as other SPs such as Canvas.
You're confusing yourself by mixing IDP and SP on the same system.)
Jaime already commented on that specific choice of entityID value. No
idea why you would do that, setting the entityID to that specific
string.
As is the case so often, the default is correct, i.e, SSP will (would
have, it you let it) create one dynamically for you. So if you don't
know what it is (and don't read the documentation) it would still be
fine. If you know what it is (and/or read the documentation) you're
free to set it to a URI that uniquely identifies this SAML SP globally.
> //not sure if all these are necessary
> 'idp' => 'drupal-idp-entityid',
> 'saml:sp:Idp' => 'drupal-idp-entityid',
> 'saml:idp' => 'drupal-idp-entityid',
No idea what brings you to that. The shipped code looks like this.
// The entity ID of the IdP this should SP should contact.
// Can be NULL/unset, in which case the user will be shown a list of available IdPs.
'idp' => NULL,
So no, only the first one would be needed, and only if you wanted to
avoid IDP discovery, i.e., only if this SP only federates with a
single IDP. Meaning if you leave the default everything will still
work, just with ann extra step of chosing the IDP during the login
process. (Which is useless if you only have one IDP, but doesn't break
anything either!)
> //documentation alluded that I only needed to define 'certificate' as the .pem file here:
> //'privatekey' => 'saml_sp.pem',
> 'certificate' => 'saml_sp.pem',
> //'certificate' => 'saml_sp.crt',
Could you please identify that part of the documentation and why you
think it tried to say something like that?
If your SAML SP has a certificate included in its SAML metadata at all
many SAML IDPs will use that to encrypt SAML assertions (or responses)
to your SP with that key. That means your SP would be unable to
decrypt them unless it had the matching private key.
I'm not going to guess whether you take the above to mean having both
the private key and the public key (certificate) in the same file on
disk.
The SP will set that itself (if accessed before authenticating at the
IDP) and that should be a URL at the same server/service/resource the
SAML SP runs in.
So likely you don't have to set that at all.
> 'acs.Bindings'
No idea why you think you need to include this in your authsource.
The defaults as shipped plus adding a 'privatekey' and 'certificate'
(as documented) are enough to make a SAML SP work.
Personally I'd suggest to start over, from scratch.
Then do nothing the documentation doesn't say you must.
Not only will you be done in 5 min, it will also just work.
> // Which attributes should be retrieved from the Drupal site.
No idea about any of the Drupal integration stuff, so can't comment.
> 'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
> //'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'
None of this should be needed, from what I remember having read so
far. Leave the defaults.
> //'attributes.NameFormat' =>
> 'urn:oasis:names:tc:SAML:2.0:attrname-format:basic',
Possible but some consider this bad practice. URI name format has the
big advantage that attribute names are globally unique (with properly
chosen URIs) so that there's no discussion about what entity X or Y
considers the proper format/content of "full_name" or whatever other
attribute, which avoids the ugly situation of having to send entity X
something else as the same attribute as entity Y (because the have
non-identical requirements for the same "basic name").
> And in the Canvas (SP) configuration, I've configured the following in the
> administration panel:
> IdP Entity ID: *drupal-idp-entityid* (this is what I have defined in
> saml20-idp-hosted.php, and also referenced as the 'idp' in
> saml20-sp-remote.php)
Correct.
> Logon URL:
> *
http://weiss.dev2.rowanonline.com/simplesaml/saml2/idp/SSOService.php*
> Logout URL:
> *
http://weiss.dev2.rowanonline.com/simplesaml/module.php/saml/sp/saml2-logout.php/default-sp*
Not if that is on canvas and asks about your IDP. Note the /sp/ in the
URL, that is for your SAML SP. Why not define seperate DNS names and
vhosts for the IDP and SP, that would make that much more clear?
(Of couse that's all Cavas' fault: We have SAML Metadata for all that,
which is machine readable, so why ask people to fill out forms
guessing at the right values when they could have just accepted an XML
file from you instead? Maybe they do, then it's your choice.)
> Certificate fingerprint:
> *B4:7A:62:5F:36:C0:2D:8A:D4:B6:11:49:68:FC:FF:32:2E:D5:2E:50* (was
> generated from the saml_sp.crt file, and matches the 'certFingerprint'
> attribute in saml20-sp-remote.php
No idea what this is about, but if this is still the Canvas GUI where
you configure your SAML IDP then it's certainly NOT something from
saml20-sp-remote.php.
Now I'm wondering what connection you're asking about, your own SP to
your own IDP? Your own IDP to Canvas? Mixing this all up in the same
thread, using config files and settings from all possible actors,
doesn't make this easier for you to understand or for anyone else to
try to help you. I get that ultimately you want ALL OF IT to work, but
you don't go at a problem like this by changing all the settings
everywhere at once.
-peter
