You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Milton Fidel vega <MV...@dian.gov.co> on 2005/07/22 22:55:12 UTC

authentication, SAML

Is correct, that the same system are the identiy provider and the
service provider supplier? (if there is not a identity provider )


this is correct?

It's a Web Service exclusively for authentication, this emit the signed
assertion via web service response after the client has autenthicated
for te web service logic, so that in following calls to the Web services
business, the messages soap of the client include the assertion in the
soap headers and it are not authenticated again.



Thanks



Re: authentication, SAML

Posted by Anne Thomas Manes <at...@gmail.com>.
IBM, Microsoft, and friends updated WS-Trust and WS-SC in Feb 2005.
They are reasonably stable at this point. The authors also announced
about two weeks ago that they will submit these specifications, as
well as an updated version of WS-SecurityPolicy to OASIS. A new
technical committee will convene in September to take responsibility
for these specs. See http://xml.coverpages.org/ni2005-07-14-a.html.

Anne

On 7/25/05, Mike Smorul <to...@umiacs.umd.edu> wrote:
> 
> Has there been any progress on SecureConversation in wss4j? The last
> postings regarding it seemed to indicate some refactoring was going on and
> the current version was not stable.
> 
> -Mike
> 
> On Mon, 25 Jul 2005, Anne Thomas Manes wrote:
> 
> > As defined by WS-Trust, a security token service (STS) is a web
> > service that issues, renews, and validates security tokens. The client
> > presents a set of claims, and if the claims provide sufficient proof,
> > the STS returns the requested token. The client can then use the token
> > to supply authentication information on subsequent SOAP requests. Each
> > SOAP request must be re-authenticated, though, unless the client and
> > server establish and maintain some type of extended security session.
> >
> > WS-SecureConversation defines a binding of WS-Trust for creating this
> > type of extended security session. WS-SecureConversation defines a new
> > token type called a security context token. When using
> > WS-SecureConversation, the client and server need to authenticate each
> > other only once at the start of the conversation.
> >
> > Anne
> >
> >
> > On 7/22/05, Milton Fidel vega <MV...@dian.gov.co> wrote:
> >>
> >> Is correct, that the same system are the identiy provider and the
> >> service provider supplier? (if there is not a identity provider )
> >>
> >>
> >> this is correct?
> >>
> >> It's a Web Service exclusively for authentication, this emit the signed
> >> assertion via web service response after the client has autenthicated
> >> for te web service logic, so that in following calls to the Web services
> >> business, the messages soap of the client include the assertion in the
> >> soap headers and it are not authenticated again.
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >
>

Re: authentication, SAML

Posted by Mike Smorul <to...@umiacs.umd.edu>.
Has there been any progress on SecureConversation in wss4j? The last 
postings regarding it seemed to indicate some refactoring was going on and 
the current version was not stable.

-Mike

On Mon, 25 Jul 2005, Anne Thomas Manes wrote:

> As defined by WS-Trust, a security token service (STS) is a web
> service that issues, renews, and validates security tokens. The client
> presents a set of claims, and if the claims provide sufficient proof,
> the STS returns the requested token. The client can then use the token
> to supply authentication information on subsequent SOAP requests. Each
> SOAP request must be re-authenticated, though, unless the client and
> server establish and maintain some type of extended security session.
>
> WS-SecureConversation defines a binding of WS-Trust for creating this
> type of extended security session. WS-SecureConversation defines a new
> token type called a security context token. When using
> WS-SecureConversation, the client and server need to authenticate each
> other only once at the start of the conversation.
>
> Anne
>
>
> On 7/22/05, Milton Fidel vega <MV...@dian.gov.co> wrote:
>>
>> Is correct, that the same system are the identiy provider and the
>> service provider supplier? (if there is not a identity provider )
>>
>>
>> this is correct?
>>
>> It's a Web Service exclusively for authentication, this emit the signed
>> assertion via web service response after the client has autenthicated
>> for te web service logic, so that in following calls to the Web services
>> business, the messages soap of the client include the assertion in the
>> soap headers and it are not authenticated again.
>>
>>
>>
>> Thanks
>>
>>
>>
>

Re: authentication, SAML

Posted by Anne Thomas Manes <at...@gmail.com>.
As defined by WS-Trust, a security token service (STS) is a web
service that issues, renews, and validates security tokens. The client
presents a set of claims, and if the claims provide sufficient proof,
the STS returns the requested token. The client can then use the token
to supply authentication information on subsequent SOAP requests. Each
SOAP request must be re-authenticated, though, unless the client and
server establish and maintain some type of extended security session.

WS-SecureConversation defines a binding of WS-Trust for creating this
type of extended security session. WS-SecureConversation defines a new
token type called a security context token. When using
WS-SecureConversation, the client and server need to authenticate each
other only once at the start of the conversation.

Anne


On 7/22/05, Milton Fidel vega <MV...@dian.gov.co> wrote:
> 
> Is correct, that the same system are the identiy provider and the
> service provider supplier? (if there is not a identity provider )
> 
> 
> this is correct?
> 
> It's a Web Service exclusively for authentication, this emit the signed
> assertion via web service response after the client has autenthicated
> for te web service logic, so that in following calls to the Web services
> business, the messages soap of the client include the assertion in the
> soap headers and it are not authenticated again.
> 
> 
> 
> Thanks
> 
> 
>