[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| 
[higgins-dev] ALF project publishes updated documents on Single	SignOn (SSO)
 | 
Dear Higgins 
community,
 
I would like to alert you to some documents on Single SignOn 
(SSO) from the Eclipse Application Lifecycle Framework (ALF) project that may be 
of interest.
 
Some background: ALF has a requirement to obtain a user 
security context from development tools when the user does something significant 
and the tool raises an ALF Event.  A typical consequence of an ALF 
Event is the triggering of a BPEL flow to update related tools to synchronize or 
adjust to that change.  The BPEL flow needs to communicate that 
security context through to all the programs that are invoked as a result 
of the event.
 
Said another way, the ALF SSO is intended to provide SSO 
for desktop, browser, server-based tools and especially tools with web service 
interfaces using a uniform and standard approach based on open 
source.  As part of the solution ALF has defined the need for an Security 
Token Server (STS).  One touchpoint with Higgins is that the STS needs to 
represent an individual (a Digital Subject) and associate that individual with 
different contexts (i.e. to determine the appropriate ID to present to each 
tool.)  ALF has written some documents describing the architecture, 
requirements, and design for the ALF SSO system and STS.  Also since ALF 
needs an STS, it will either need to build one or, better still, make use of one 
that IBM has had some discussions on the Higgins mailing list.  ALF 
has a near-term need for SSO, but ALF's focus on development tool 
interoperability and integration,  not security, so ALF is very interested 
in working closely with the Higgins project.
 
The newest in the series of documents on ALF Single-SignOn has been updated on the ALF 
website (http://www.eclipse.org/alf) to version 
00.14:
 http://www.eclipse.org/alf/includes/ALF_Security_Technology_and_Design_draft.pdf   The document 
covers the design and sources of technology to implement SSO  for 
ALF.  The goal of the document - to describe the design and 
technology  to be used in sufficient detail to allow the planning for 
implementing ALF  SSO to be accomplished - has been achieved.  The 
document includes an  Implementation Plan that phases the 
capabilities.  That document is 
ready for a thorough review.  
We solicit community review, feedback 
and discussion.
  
The original document in the series, ALF Security 
Architecture: SSO (See: http://www.eclipse.org/alf/includes/ALF_Security_Architecture_SSO.pdf ) has also been updated to version 00.26.  The 
Architecture document covers the entities involved, protocols used, and 
architecture of the ALF SSO system.  The latest version on the ALF website 
updates the text and figures to flesh out some remaining sections of the 
document and reflect what has been learned during the Technology and Design 
effort.
 
You are invited to read both documents, especially the 
newer Design and Technology draft, and contribute to them by providing 
text, feedback,  implementation experiences, etc. Areas where feedback 
would be most welcome are:
 1. The assessment of the open source 
technologies proposed, (or are there better alternatives?) - that is, are 
we making the best technology choices for building ALF SSO?
 2. Does the 
ordering of the capabilities into implementation phases meet the community 
needs?
 3. Is anyone interested 
in helping to build the SSO 
system? 
 
Regards,
Brian
Brian Carroll
Architect, Eclipse ALF 
project
www.eclipse.org/alf
Serena Fellow
Serena 
Software
(ofc) 
 (503) 617-2436
(cell)  (503) 318-2017
bcarroll@xxxxxxxxxx 
 
********************************************************************** 
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.