Getting the big picture - ESOE Users

Message from discussion Getting the big picture
Received-SPF: pass (google.com: domain of bedd...@intient.com designates 209.85.200.171 as permitted sender) client-ip=209.85.200.171;
Message-ID: <48DC6088.1070803@intient.com>
Date: Fri, 26 Sep 2008 14:09:44 +1000
From: Bradley Beddoes <bedd...@intient.com>
Organization: Intient Pty Ltd
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------090200050805060505080009"
To: esoe-users@googlegroups.com
Subject: Re: [esoe-users] Getting the big picture
References: <da1ec9d3-4e82-4305-ae1a-8bfe7ec64e08@p10g2000prf.googlegroups.com>
In-Reply-To: <da1ec9d3-4e82-4305-ae1a-8bfe7ec64e08@p10g2000prf.googlegroups.com>

--------------090200050805060505080009
Content-Type: text/plain; charset=ISO-8859-1


Hi Phil,
Sounds like a large interesting project.

There is essentially a 1:1 mapping between SPEP and application (though 
you can configure a single SPEP to reside over multiple WAR files in a 
tomcat instance for example). Each SPEP instance can then have multiple 
policy files to enforce access constraints as required.

Your flows are almost correct. However SPEP does no local 
authentication, nor does it pass on a ticket to the application, it 
physically sits in the request path and does validation on your behalf.

Also a user authenticates to the core ESOE system once per browser 
session, via integrated authentication, user/pass, token or whatever you 
choose. The first visit to any SPEP instance invokes a SAML exchange 
between the SPEP instance and core ESOE deployment. This creates a new 
session for the SPEP and does identity attribute transfer.

Logoff also is global, we call this Single Logout. You log out of one 
application and your logged out of them all.

Does that assist ?

regards,
Bradley

Phil Gates wrote:
> I'm currently looking into implementing SSO for a wide range of web
> sites such as Blackboard, Google Apps, Outlook Web Access and a
> growing number of in house Ruby on Rails sites. These sites are
> accessed both internally and externally by staff/students with AD
> accounts and parents/agents with login details stored in various
> databases. We are wanting to pull all this together and present it
> within the Blackboard portal system. ESOE looks like it may have the
> feature set required to bring all this together.
> 
> I'm assuming that you require an appropriate SPEP instance for each
> application server technology eg java, apache and IIS. Do you also
> require separate instances for each different security scenario or is
> this governed by the Service Authorization Policy for each service/
> website?
> 
> I'm just trying to piece together the big picture of how the various
> components work and flow together. (sorry about the format, may
> require wide screen)
> 
> 1 User's first access to a protected site
> Browser		=>	Application Server		SPEP		ESOE		LDAP/DB
> 2 Application Server redirects to SPEP
> Browser			Application Server	=>	SPEP		ESOE		LDAP/DB
> 2a Uses integrated authentication if available
> or 2b SPEP displays login screen
> Browser		<=	Application Server	<=	SPEP		ESOE		LDAP/DB
> 3 SPEP validates with ESOE
> Browser			Application Server		SPEP	=>	ESOE		LDAP/DB
> 4 ESOE validates against the appropriate data source
> Browser			Application Server		SPEP		ESOE	<=>	LDAP/DB
> 5 ESOE returns session ticket to SPEP
> Browser			Application Server		SPEP	<=	ESOE		LDAP/DB
> 6 SPEP returns session ticket to Application Server
> Browser			Application Server	<=	SPEP		ESOE		LDAP/DB
> 7 Application Server begins user session based on details in session
> ticket
> 8 Application returns session ticket to browser
> Browser		<=	Application Server		SPEP		ESOE		LDAP/DB
> 9 Browser stores session ticket as cookie
> Browser			Application Server		SPEP		ESOE		LDAP/DB
> 
> 
> 1 User's subsequent access to a protected site with ticket
> Browser		=>	Application Server		SPEP		ESOE		LDAP/DB
> 2 Application Server validates ticket with SPEP
> Browser			Application Server	=>	SPEP		ESOE		LDAP/DB
> 3 SPEP validates ticket with ESOE
> Browser			Application Server		SPEP	<=>	ESOE		LDAP/DB
> 4 SPEP returns validated to Application Server
> Browser			Application Server	<=	SPEP		ESOE		LDAP/DB
> 5 Application returns content to browser
> Browser		<=	Application Server		SPEP		ESOE		LDAP/DB
> 
> 
> 1 User logs off one site
> Browser		=>	Application Server		SPEP		ESOE		LDAP/DB
> 2 Application Server invalidates ticket with SPEP
> Browser			Application Server	=>	SPEP		ESOE		LDAP/DB
> 3 SPEP invalidates ticket with ESOE
> Browser			Application Server		SPEP	<=>	ESOE		LDAP/DB
> 4 SPEP returns in validated to Application Server
> Browser			Application Server	<=	SPEP		ESOE		LDAP/DB
> 5 Application server ends user session
> 
> 1 User accesses another protected site with ticket
> Browser		=>	Application Server		SPEP		ESOE		LDAP/DB
> 2 Application Server validates ticket with SPEP
> Browser			Application Server	=>	SPEP		ESOE		LDAP/DB
> 3 SPEP validates ticket with ESOE
> Browser			Application Server		SPEP	=>	ESOE		LDAP/DB
> 4 ESOE returns invalidated to SPEP
> Browser			Application Server		SPEP	=>	ESOE		LDAP/DB
> 5 SPEP returns invalidated to Application Server
> Browser			Application Server	<=	SPEP		ESOE		LDAP/DB
> 6 Application server ends user session
> 9 Application server instructs browser to destroy session ticket
> Browser		<=	Application Server		SPEP		ESOE		LDAP/DB
> 
> Cheers,
> 
> Phillip
> > 


-- 
Bradley Beddoes
Lead Software Architect
Intient Pty Ltd

http://www.intient.com

--------------090200050805060505080009
Content-Type: text/x-vcard; charset=utf-8
Content-Disposition: inline;
	filename="beddoes.vcf"

begin:vcard
fn:Bradley Beddoes
n:Beddoes;Bradley
org:Intient Pty Ltd
adr:;;;;;;Australia
email;internet:bedd...@intient.com
title:Lead Software Architect
tel;work:07 31024560
tel;cell:0413 678 802
url:http://www.intient.com
version:2.1
end:vcard


--------------090200050805060505080009--