Mailing-List: contact fx-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of atmanes@gmail.com designates
 64.233.184.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=leMaQLSPcM3wM0eHDln5xwKA2vVOrLQQyav4f6z0LDomz3nOP1gITgYhe+tM2umozS1Bv9AaV5ebYjC4vgKWxTvuyiUwMzm61ccWSUzS4XLysieiqTu8qJfE/GQ1qTfbboezSs7bHQXPIBEvZ7Ju3S/w3rBlCuEcwEgNrdInfUc=
Message-ID: <bf414ee605072518382e3a9b72@mail.gmail.com>
Date: Mon, 25 Jul 2005 21:38:16 -0400
From: Anne Thomas Manes <atmanes@gmail.com>
Reply-To: Anne Thomas Manes <atmanes@gmail.com>
To: fx-dev@ws.apache.org
Subject: Re: authentication, SAML
In-Reply-To: <Pine.LNX.4.60.0507252059210.31558@loach.umiacs.umd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1122065712.4672.6.camel@l00073031.dian.gov.co>
	 <bf414ee60507251743209d4250@mail.gmail.com>
	 <Pine.LNX.4.60.0507252059210.31558@loach.umiacs.umd.edu>

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 <toaster@umiacs.umd.edu> wrote:
>=20
> Has there been any progress on SecureConversation in wss4j? The last
> postings regarding it seemed to indicate some refactoring was going on an=
d
> the current version was not stable.
>=20
> -Mike
>=20
> On Mon, 25 Jul 2005, Anne Thomas Manes wrote:
>=20
> > 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 <MVEGAV@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 signe=
d
> >> assertion via web service response after the client has autenthicated
> >> for te web service logic, so that in following calls to the Web servic=
es
> >> business, the messages soap of the client include the assertion in the
> >> soap headers and it are not authenticated again.
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >
>