It would be nice to close the loop around the claims
that can be requested as part of the RST by describing those claims in
ws-securitypolicy. I believe the ws-trust spec already states that those claims
would be dictated by policy. What better place than in a security policy as
these tokens are needed for the purposes of security. From the statements being
made about security policy only being about wire formats, maybe
ws-securitypolicy is mis-named. Maybe it should be something like
ws-soapsecuritypolicy that should just reference other specs that can more fully
describe all security requirements around the tokens.
Tony
From: Anthony Nadalin
[mailto:]
Sent: Friday, April 07, 2006 12:05
PM
To: Whitehead, Greg
Cc: Scott Cantor; Symon Chang; Tony
Gullotta;
Subject: RE: [ws-sx] Issue 31:
Token properties
The RST has elements/attributes that can be used to describe what type of
token is requested, are you saying this is not adequate ?
I'm saying that WS-SecurityPolicy as described in the charter id to express
the conditions and restrictions on the wire formats defined by WSS, WS-Trust and
WS-SecureConversation and that contents of the token are opaque to the wire
formats.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
'
src="gif00103.gif" width=16>"Whitehead, Greg"
<>
"Whitehead, Greg"
<>
04/07/2006 12:58 PM
To
Anthony Nadalin/Austin/IBM@IBMUS
cc
"Scott Cantor" <>, "Symon Chang"
<>, "Tony Gullotta"
<>,
<>
Subject
RE: [ws-sx] Issue 31: Token
properties
Each
relying party that is protecting a resource based on the token it receives in a
WSS Security header will have some policy about what that token needs to say.
While WSS can be neutral to that, I don't see how the STS can be... otherwise,
how will a WSC be able to get a satisfactory token from the STS?
Are you
saying that it's sufficient for a WSP to state that it requires SAML tokens, and
that ANY SAML token will do?
-Greg
Trustgenix has been acquired by
HP. Please make a note my new email address:
-----Original Message-----
From:
Anthony Nadalin [mailto:]
Sent: Fri
4/7/2006 8:03 AM
To: Whitehead, Greg
Cc: Scott Cantor; Symon Chang; Tony
Gullotta;
Subject: Re: [ws-sx] Issue 31: Token
properties
Greg,
It's enough for WS-Security,
WS-Trust, etc to say I want a SAML token as
that is all the is profiled in
WSS, there is nothing that the wire format
of these specifications depend on
in regards to token specifics.
Anthony Nadalin | Work 512.838.0085 | Cell
512.289.4122
Greg Whitehead
<greg.whitehead@h
p.com>
To
Anthony Nadalin/Austin/IBM@IBMUS
04/07/2006 07:15
cc
AM
"Symon Chang"
<>, "Scott
Cantor"
<>, "Tony
Gullotta" <>,
Subject
Re: [ws-sx] Issue 31: Token
properties
It seems to me that an RST needs to
specify the desired properties of the
requested token in enough detail that
the STS can satisfy the request
without relying on out-of-band
information.
As has already been pointed out, it's not enough to say that
you want a
SAML token.
-Greg
On Apr 7, 2006, at 12:34 AM,
Anthony Nadalin wrote:
Symon,
The key part of what you quote is "conditions and restrictions on
the
wire formats defined by OASIS Web
Services Security [1], WS-SecureConversation [2] and WS-Trust [3]
to
a
specific set of typed message
interchanges." well Services Security,
WS-SecureConversation and WS-Trust don't depend on any formats of
the
tokens for wire formats, applications may but these
specifications
don't.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
<graycol.gif>
"Symon Chang"
<>
"Symon
Chang" <
>
<ecblank.gif>
04/06/2006 12:36 PM
To
<ecblank.gif>
"Scott Cantor" <>,
"Tony Gullotta"
<
>,
Anthony
Nadalin/Austin/IBM@IBMUS, <
>
<ecblank.gif>
cc
<ecblank.gif>
<ecblank.gif>
Subject
<ecblank.gif>
RE: [ws-sx] Issue 31: Token
properties
<ecblank.gif>
<ecblank.gif>
The following is from the charter for our WS-SX TC:
"WS-SecurityPolicy [4] uses the facilities of WS-Policy [5]
to
express
the conditions and
restrictions on the wire formats defined by OASIS
Web
Services Security [1], WS-SecureConversation
[2] and WS-Trust [3] to
a
specific
set of typed message interchanges."
From this
statement, there is no reason to define the WSS token
properties somewhere else. WS-SecurityPolicy has to define
properties
of
token in the
WS-Security spec.
For example, Username Token
with/without nonce or created tags should
be
definable in the security policy, so that the Policy
Enforcement
Point
can enforce the
policy accordingly.
Symon Chang, CISSP
Sr. Security Architect
Blue Titan
Software
-----Original Message-----
From: Scott Cantor [mailto:]
Sent: Thursday, April 06, 2006 9:53 AM
To: 'Tony
Gullotta'; 'Anthony Nadalin'
Cc:
Subject: RE: [ws-sx] Issue 31:
Token properties
> I would think that at a minimum
we should look at properties
> required to ensure the
tokens can be authenticated properly
> like in my
first example.
That applies to SAML as well, i.e.
SubjectConfirmation. It's
meaningless
to
just say "SAML token".
I would say there should be token profiles of many of these specs,
if
not
here, fine, but
somewhere.
--
Scott
(See attached file:
graycol.gif)(See attached file: pic11814.gif)(See attached file:
ecblank.gif)
