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

dokter@goldmund-wyldebeast-wunderliebe.com

1

Contents

• Existential aﬀairs;

• 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 (ﬁve) nine’s (99.999)
Your system is delivering its service to the user 99.999% of the time it is
needed. (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/wk
99.99% 52.6 min 4.32 min 1.01 min
99.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 ﬁrst: 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;

ﬂoating IP, and other services can be transported across nodes connect over
two 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 and
ZEO.


And what about caching?

Are we happy yet?


Single Sign-On

Single Sign-On is:

• authentication process where a user presents credentials once and gets
authenticated 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 generates
this 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 ﬁnal result

What was that again on complexity?


Issues

• Loosing sessions: sticky sessions?

• We haven’t really ﬁnished: monitoring.


Ceterum censeo MicroSoftem esse delendam


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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

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

Ähnlich wie Duco Dokter - Plone for the enterprise market: technical musing on caching, Clustering and Single Sign-On (20)

Mehr von Vincenzo Barone

Mehr von Vincenzo Barone (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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