RE: [higgins-dev] STS Requirements

["Brian Carroll" <BCarroll@xxxxxxxxxx>]

Yes. That is the essence. 
Brian
________________________________

From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Wednesday, April 19, 2006 8:34 PM
To: Higgins (Trust Framework) Project developer discussions
Cc: Higgins (Trust Framework) Project developer discussions;
higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] STS Requirements



So to net this out:

A "basic" STS that supported RST with UNT and returning a RSTR with WSS
SAML 1.1 Token Profile token would work with the ability to plug-in
other token profiles (defined in WSS TC) and transformations. The STS
would support either wsp:Policy element or as wsp:AppliesTo element in
the RST.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
 "Brian Carroll" <BCarroll@xxxxxxxxxx>




				"Brian Carroll" <BCarroll@xxxxxxxxxx> 
				Sent by: higgins-dev-bounces@xxxxxxxxxxx


				04/19/2006 07:24 PM 
	
	Please respond to
"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>

 

To

"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>	


cc

	


Subject

RE: [higgins-dev] STS Requirements	
	 	

Hi Tony,

Wonderful news!

The Eclipse Application Lifecycle Framework (ALF) project has defined a
need for an STS to issue, (perhaps renew), validate, and terminate
security tokens. A full description can be found on the Eclipse ALF
site: http://www.eclipse.org/alf <http://www.eclipse.org/alf>  ,
especially the SSO paper at 
http://www.eclipse.org/alf/includes/ALF_Security_Architecture_SSO.pdf
<http://www.eclipse.org/alf/includes/ALF_Security_Architecture_SSO.pdf> 

ALF has several use cases which include:
- SSO from web applications, where the user is accessing it via a
browser
- SSO from desktop or Eclipse applications
- Validating a token that is passed via web services through a BPEL
process and needs to convey a security context to all the programs
initiated while executing the process

We had in mind: 

	- Using SAML 1.1 or SAML 2.0 Assertions as the token format, but
extending them with ALF-and BPEL-flow-specific information.
	- Having the STS accept various forms of credentials, starting
with UsernameToken, and eventually supporting BinaryTokens such as a
Kerberos token (as you might obtain from an operating system), and x.509
certificates as you might find installed on a server or smart card. And
converting these various forms of credentials to SAML Assertion tokens
	- Having the ability for the STS (based on the policy of
different server applications) to provide alternate forms of
credentials, for those applications that may not accept a SAML token
(such as a mainframe invoked that uses RAC and expects a name and
password)
	- We had hoped to initially use WS-Trust and WS-Federation (for
signoff), with a future notion of supporting the SAML Protocol (unless
that converged with WS-Trust in the meantime)


There is more, but that covers the main points. I would be happy to
provide more details, use cases, etc.

Regards,
Brian



________________________________

From: higgins-dev-bounces@xxxxxxxxxxx [
mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Wednesday, April 19, 2006 3:47 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: [higgins-dev] STS Requirements


So in trying to pull together an STS for the Higgins Project, I would
like to understand the requirements that folks have, like token types,
token options supported ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
********************************************************************** 
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.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev