Next in thread →
Next in month →
RE: [ws-sx] Issue 31: Token properties
Ok. I was more concerned about forcing other groups to have
to extend the existing incomplete token assertions but I didn't think about it
the way Chris described in today's call. I guess someone else could still define
an alternative SAML token assertion that the community could adopt instead of
the one in WS-SX if they'd rather not extend the current
one.
I am still a bit concerned about who would develop these
more complete assertions for Username and X.509 tokens since I don't know of an
existing TC other than this one that is dealing with them. I think I understand
where you are coming from about not having to validate the token in order
to verify signatures and decrypt messages, but I still think we're missing
something in terms of security if we can't be sure that the tokens are
valid and the claimed identity is not stolen. I don't think that is
application specific.
Tony
From: Anthony Nadalin
[mailto:]
Sent: Wednesday, April 12, 2006 1:04
AM
To: Tony Gullotta
Cc: Scott Cantor; Whitehead, Greg;
Symon Chang;
Subject: RE: [ws-sx] Issue 31:
Token properties
Tony,
The purpose of WS-SecurityPolicy is to describe the conditions
and restrictions on the wire formats for WSS, WS-Trust and
WS-SecureConversation. So I don't think that its mis-named, it could be that you
are looking for more of how applications specify specific token policies. The
charter points out that WS-SecurityPolicy is about wire format.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
'
src="gif00131.gif" width=16>"Tony Gullotta"
<>
"Tony Gullotta"
<>
04/11/2006 06:49 PM
To
Anthony Nadalin/Austin/IBM@IBMUS, "Whitehead, Greg"
<>
cc
"Scott Cantor" <>, "Symon Chang"
<>,
<>
Subject
RE: [ws-sx] Issue 31: Token
properties
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="gif00140.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)
Next in thread →
Next in month →