drupal and diversity of single sign-on systems
Post on 27-Jul-2015
992 Views
Preview:
TRANSCRIPT
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: alexander.schedrov@gmail.com Twitter: @alexschedrov
top related