OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] End to end scenario


-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Thursday, May 06, 2004 2:24 PM
To: 'Simon Fell'; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] End to end scenario

> I have a SOAP service that requires authenticated access, one of the 
> ways to get authenticated access is to send a SAML assertion in a 
> WS-Security header (as per
> pec/html/ws-security-xml-tokens.asp) In this case does the SAML 
> assertion follow the same pattern as the browser/POST profile ?, i.e.
> there's a bearer confirmationmethod ?

There is no SSTC-documented profile defined for the scenario you
describe, therefore the answer is potentially yes or no. You could use
bearer, or anything else you like.

> Can I just do a samlp:AuthenticationQuery to a local SAML server to 
> obtain the assertion to send in the SOAP message to our server ?

Not if you follow the spec, no. There is no non-browser profile for how
you would obtain an assertion because there was no other use case
profiled. The bootstrap process is missing, essentially, but
AuthenticationQuery is not that process.

> It seems like the browser/POST profile does a good job of tackling web

> apps, but there doesn't seem to be an equivilent for web services, is 
> there some document/profile I'm missing, or is this something that'll 
> get covered in SAML 2.0 ?

You're not missing anything. And, no, there is no profile in the current
drafts for 2.0 that specifically addresses your use case. There is a
significantly increased set of potential building blocks for the use
case, one piece being an AuthnRequest protocol message that is defined
to act as a authenticated request to obtain an authn assertion. However,
it's a fairly wide-open message with a lot of optionality, and doing it
interoperably for a web service would require a more detailed profile,
or set of rules to follow.

One place you might look, if for no other reason than because it
illustrates the options involved, is the Liberty Alliance WSF security
mechanisms specification, which builds on SAML 1.1 and the WSS SAML
profile to define the kinds of things you're talking about. There's a
companion spec in WSF that describes a SOAP authentication service
architected around SASL that is another example of how one might
authenticate a SOAP client and get back a token like a SAML assertion.



-- Scott


To unsubscribe from this list, send a post to
saml-dev-unsubscribe@lists.oasis-open.org, or visit

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]