| |
ESOE Users |
Hi Phil, There is essentially a 1:1 mapping between SPEP and application (though Your flows are almost correct. However SPEP does no local Also a user authenticates to the core ESOE system once per browser Logoff also is global, we call this Single Logout. You log out of one Does that assist ? regards, > I'm assuming that you require an appropriate SPEP instance for each > I'm just trying to piece together the big picture of how the various > 1 User's first access to a protected site > 1 User's subsequent access to a protected site with ticket > 1 User logs off one site > 1 User accesses another protected site with ticket > Cheers, > Phillip
Sounds like a large interesting project.
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.
authentication, nor does it pass on a ticket to the application, it
physically sits in the request path and does validation on your behalf.
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.
application and your logged out of them all.
Bradley
> 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.
> 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?
> components work and flow together. (sorry about the format, may
> require wide screen)
> 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
> 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
> 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
> 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
Bradley Beddoes
Lead Software Architect
Intient Pty Ltd
|
|
beddoes.vcf < 1K Download |