[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
![Inactive hide details for "Brian Carroll" <BCarroll@xxxxxxxxxx>]()
"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> |
|
|
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 ,
especially the SSO paper at 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
