Duco Dokter - Plone for the enterprise market: technical musing on caching, Clustering and Single Sign-On

Enterprise Plone:(Rather) Complex Infrastructures

October 11, 2007, Plone Conference, Napoli

Duco Dokter

[email protected]

1

Contents

• Existential affairs;

• High Availability;

• More existentialism;

• Single Sign-On;

• Load-balancing;

• Caching... GOTO [other talks].

Duco Dokter, Goldmund, Wyldebeast & Wunderliebe, 11 october 2007 2

A not so complex setup


You wanted it more fancy?


The enterprise market

• Usually highly demanding in terms of availability;

• not necessarily because they actually need it though...;

• mission critical applications;

• complex existing infrastructure;

• lots of (web)services, legacy.


What is High Availability?

The myth of the (five) nine’s (99.999)

Your system is delivering its service to the user 99.999% of the time it isneeded. (Myth: so the downtime of your actual ‘service’ is negligable...)

Does anyone know how much time that leaves for breakdowns?


About this much

uptime downtime/yr downtime/mnth downtime/wk99.99% 52.6 min 4.32 min 1.01 min99.999% 5.26 min 25.9 sec 6.05 sec

So one broken disk in your data center:

• that takes 5 minutes to replace: 1 year used;

• sadly the data center is ten minutes away by bike: three years worth;

• and you have no spare disk and need to go to the shop first: 12 years gone;

• ... but the shop needs to order that at Fujitsu...


How?

• assert risk for components, both hardware and software;

• remove ’single-point-of-failure’ spots, id;

• calculate possibility of system failure;

• avoid complexity!


HA Cluster setup

• throw in more machines;

• throw in more Zope instances (servers);

• use heartbeat;

floating IP, and other services can be transported across nodes connect overtwo interfaces: i.e. serial and ethernet

Syncing: drbd, syncpozo, zeoraid, fs solutions


New setup, as HA cluster

Do we still have a problem? Yep: no global redundancy


Why leave your slave whithering away? Adding LB andZEO.


And what about caching?

Are we happy yet?


Single Sign-On

Single Sign-On is:

• authentication process where a user presents credentials once and getsauthenticated for more than one application;

• a ‘meta’ session is created.

Web SSO: the same story, but only for web applications


Why Single Sign-On?

• user experience;

• less user separate user accounts;

• focal point in security administration.


How?

• One trusted source;

• a trust relationship between the source and ‘clients’;

• a trusted & clear protocol for authentication.


Plone SSO

• More plone sites within same user session;

• Plone as front-end for other apps;

• other (non-Plone) web apps in same session;

• non-web apps in same session;

• Plone login based on machine login (not in scope, but think NTLM).


CAS

• SSO server built at Yale university;

• Java Servlet/JSP technology;

• (reasonably) well documented;

• source code available;

• free licence;

• open and clear protocol.


Plone & CAS

Prerequisites:

• CAS4PAS;

• PlonePAS.

Optional: PloneCASLogin


Steps: Session 1

1. http request to Plone site A;

2. inlog link kiezen naar CAS server of authenticatie redirect (CAS4PAS) over HTTPS;

3. login on CAS server;

4. CAS sets cookie;

5. redirect back to callback service with ticket;

6. validation ticket to CAS server;

7. CAS server removes ticket and gives ’ok’ + netID;

8. response (with Plone cookie).


Why the validate step?

Because of redirect to service: might not be secured.

So: a token is given, and Plone uses this to actually validate. CAS generatesthis token, and receives it to give back the user id.


Steps: Session 2

1. http request to Plone site B;

2. click on login link to CAS server or receive authenticatie redirect (CAS4PAS);

3. CAS service recognizes existing session (based on cookie);

4. redirect back to service with new ticket;

5. validation with ticket;

6. CAS removes ticket, and says ’ok’ + Net ID;

7. response.


Architectuur


Back end

• LDAP

• SQL

... but fully pluggable.


So...

• more Plone sites, 1 account;

• Plone site as front end for other sites;

• Mix of Plone and other web systems;

• Mix of Plone and non web systems.


The final result

What was that again on complexity?


Issues

• Loosing sessions: sticky sessions?

• We haven’t really finished: monitoring.


Ceterum censeo MicroSoftem esse delendam


Business

Duco Dokter - Plone for the enterprise market: technical musing on caching, Clustering and Single Sign-On