looking for thoughts on IDP deploy architectures

[Jim Fox]

We generally use clustering for both scalability and high availability, and put at least one of the cluster members in a geographically distant location.  We do this for our IdPs and all supporting services, including our groups service.

Our persistent Ids are stored in a local database on each IdP system, so none is dependent on any other.

We store consents, for now this is 'I agree' to something, as group memberships, so they have the same redundency as the groups service.

We haven't yet needed to store uApprove or OAuth, specific SP and attribute consents.  I suspect they will need a database.  The obvious thing to do on database failure is to ask for consent again.

Jim
 
On Feb 15, 2013, at 11:12 AM, Steven Carmody wrote:

> Hi,
> 
> Over the last few years many of us have seen our Shibboleth IDP 
> infrastructure evolve to become part of the core infrastructure, and to 
> have the same set of high throughput, high availability, failover 
> requirements (including participating in the local Disaster Recovery 
> framework) that the more traditional business systems already have.
> 
> We're interested in hearing how other sites are approaching these 
> requirements. I've included some points below, and would appreciate 
> hearing how others have approached these problems. And please add any 
> other info you think may be relevant.
> 
> Thanks in advance!
> 
> high throughput -- traditionally, sites have run clustered IDPs, using 
> various approaches to clustering (terracotta, jboss, stateless IDPs, 
> etc). A newer approach is virtualization, allowing a site to dynamically 
> expand and contract the "size" of the machine running an IDP). Is anyone 
> doing that ?
> 
> high availability, failover -- traditionally, sites have run multiple 
> IDPs behind a load balancer. If an IDP encounters problems, or is 
> undergoing maintenance, it is removed from the pool. Are sites using 
> other approaches to this requirement ?
> 
> High availability could also extend to services that the IDP may rely 
> on. Authentication (perhaps kerberos) and attribute stores (perhaps 
> ldap) are obvious examples, and are easy to also run with the "multiple 
> server" approach.
> 
> less obvious is if the IDP requires a database (eg for storing 
> persistent ID values, or perhaps consent decisions). What approaches are 
> sites using to address high availability and failover requirements for 
> the DB ?
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net