Drupal and diversity of SSO systems Drupal Cafe Kyiv, 2015 Alexander Schedrov aka sanchiz Team Lead, FFW
Jul 27, 2015
Drupal and diversity of SSO systems
Drupal Cafe Kyiv, 2015
Alexander Schedrov aka sanchiz Team Lead, FFW
Alexander Schedrov aka sanchiz
Team Lead, FFW (ex ProPeople)
I love Open Source
I'm contributor to Open Source
That’s why I’m here
Ukraine, Kyiv
What is SSO
Single sign-on (SSO) is a session/user authentication process that permits a user to enter one name and password
in order to access multiple applications.
Cases when SSO is right solution
• One authentication server and one set of credentials for all services/sites
• Add new production into existing network and connect your applications together
• Share user data across services
Difference
Authentication: recognizes who you are.
Authorization: know what you are allowed to do, or what you allow others to do.
In most cases SSO focus only on authentication
1. Shared tables and cookies
Implementation// Current site database. $databases['default'] = array( 'default' => array( 'database' => 'current_database', 'username' => 'root', 'password' => 'root', 'host' => '127.0.0.1', 'port' => '', 'driver' => 'mysql', 'prefix' => '', ), );
// Primary site database with users. $databases['primary_site'] = array( 'default' => array( 'database' => 'primary_database', 'username' => 'root', 'password' => 'root', 'host' => '127.0.0.1', 'port' => '', 'driver' => 'mysql', 'prefix' => '', ), );
settings.php:
// Value: "primary_database." $shared = $databases['primary_site']['default']['database'] . '.';
// Point tables to primary site. $databases['default']['default']['prefix'] = array( 'default' => '', 'authmap' => $shared, 'sessions' => $shared, 'permissions' => $shared, 'role' => $shared, 'users' => $shared, 'users_roles' => $shared, );
$cookie_domain = '.drupal.org';
https://www.drupal.org/node/22267
settings.php:
CookiesCookies and sessions stored in Drupal database
Advantages• Simple configuration
• Perfectly works for SSO for drupal sites
• Sharing and syncing data (fields)
• Cookie-based default authentication system
• The same UID
Limitations• The same top-level domain
• Shared database credentials
• Unexpected results, depending on which tables you choose to share
• Security issues and security holes
• Broken version updates
2. Bakery Single Sign-On System
Implementation
• Enable “Bakery” module as admin
• Configure master site
• Configure slave sites
https://www.drupal.org/project/bakery
Advantages
• Simple configuration
• Sites may be on different servers/hosting service
• Cookie-based
• Good documentation(even Vagrant box)
Limitations• Logins are handled by the master site only
• The same top-level domain
• No data syncing
• Different UID
• Conflicts between accounts
• No fallback for specific users
3. LDAP
LDAP
The Lightweight Directory Access Protocol (LDAP) project provides integration with LDAP server
for authentication, user provisioning, authorization.
https://www.drupal.org/project/ldap
Submodules LDAP• ldap_servers
• ldap_users
• ldap_authentication
• ldap_authorization
• ldap_sso
• ldap_feeds
• ldap_views
Provisioning, CRUD
Authentication
LDAP provides• Provisioning from LDAP to Drupal
• Provisioning from Drupal to LDAP
• Syncing of data
• Syncing of roles and other attributes(depends on schema)
• User binding
phpLDAPadmin if you have no UI
Advantages• A lot of development frameworks have
support for communication with LDAP
• Users can have complex group membership
• Integrated with Organic Groups
• You can build your own schema inside LDAP
• Flexible solution, API, docs
Limitations
• Complex configuration
• Should be installed on separate server
• Very complex for small solutions
• Deployment requires some planning
4. LDAP + CAS
CAS
You can delegate authentication to CAS server.
It may replace Drupal authentication (ldap_authentication, ldap_authorization
and ldap_sso).
https://www.drupal.org/project/cas
https://wiki.jasig.org/display/CASC/phpCAS
Advantages• Flexible solution
• CRUD and syncing
• CAS is the one who responsible about authentication
• You can easily change Identity Provider
• Different types of authentication: with and without redirection to dedicated page
Limitations• Complex configuration, that includes LDAP
and CAS servers
• Hard to debug and find errors
• Very complex for small solutions
• Deployment requires some planning
• You need a lot of servers for development, test and production environments
5. SimpleSAMLphp
SimpleSAMLphpSimpleSAMLphp is an award-winning application
written in native PHP that deals with authentication and authorization.
https://www.drupal.org/project/simplesamlphp_auth
Powerful and secure SAML
Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider
and a service provider.
Terms
Identity Provider(IP) is responsible for providing identifiers for users looking to interact with a system and possibly providing other information about the user that
is known to the provider.
Service Provider(SP) is a system that communicate with Identity Provider and make an authentication
control.
Capabilities• SimpleSAMLphp has own storage for
sessions (Memcache, SQL, PHPsession)
• Work with Service Providers that supports SAML.
• Work with many Identity Providers and with IPs that supports SAML. LDAP, MySQL, files, Drupal database and so on.
Configuration• Install simpleSAMLphp library
• Configure IP and SP
The most popular cases in Drupal wold
• Drupal site as Identity Provider
• SimpleSAMLphp as Service Provider
• Dedicated MySQL database as Identity Provider
• SimpleSAMLphp as Service Provider
• Shibboleth as Identity Provider and Service Provider
Advantages• It written on PHP
• Easy to debug
• May be as Service Provider and Identity Provider
• Drupal site may be as Identity Provider
• You can exclude roles, users from authentication process
Limitations
• SimpleSAMLphp library and sites should be on the same server
• Login always will be via simpleSAMLphp page
• No easy way to save custom information into Identity Provider
6. Custom solutions
Reasons to use
Only when existing solutions don’t solve your problems.
Custom Solutions
• Services
• oAuth and OpenID
• Custom code :)
Shared tables Bakery LDAP LDAP +
CASSimpleSA
MLphp Custom
Simple ✓ ✓ × × × -
CRUD ✓ ✓ ✓ ✓ × -
Don’t needtop-level domain
× × ✓ ✓ ✓ -
Secure × ✓ ✓ ✓ ✓ -
Flexibility × × ✓ ✓ ✓ -
Extendable × × ✓ ✓ ✓ -
Different servers × × ✓ ✓ ✓ -
Thank you!
Drupal.org: https://www.drupal.org/u/sanchiz GitHub: https://github.com/Sanchiz Blog: http://sanchiz.net Email: [email protected] Twitter: @alexschedrov