[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - sstc-saml-holder-of-key-browser-sso-draft-03.odt
> This is all of ID-WSF, right? I'm looking for a standalone profile to > retrieve a h-o-k assertion from a SAML IdP. Does such a profile > exist? Yes. I can't reference it because the only thing posted is the ZIP. > > The SAML Token Service profile and SOAP binding specs do exactly what you > > want for SOAP applications. > > Well, I don't see a SAML Token Service profile in that mountain of > files. It's in the AS document. > Given that 1) the vast majority of IdPs authenticate users via > username/password (in my experience, at least), and 2) there appears > to be at least a mild backlash against SOAP in the marketplace, I > would say that an HTTP-based token service is not only viable, but > necessary at this point. I think it's needless duplication with fewer features. But if I honestly thought that *anybody* could be won over just by pulling SOAP out of there, I'd have done it a long time ago. The real problem is not getting tokens, but using them. Without those profiles, it doesn't matter. > Are you referring to WS-Addressing? I haven't examined this aspect of > ID-WSF in detail, but I wonder if the use of WS-A here interferes with > the use of WS-A in applications based on WS-ResourceFramework (which > is the totality of grid applications)? No, I wasn't talking explicitly about WS-Addressing, but there's probably some basic use of it in there. Liberty defines a couple of headers for housekeeping, and then there's WS-Security, but even that's basically just used for timestamping if you wanted to use, say, basic-auth for authentication. Since all I'm talking about is SOAP between the client and the IdP, I don't see why a conflict with WSRF would matter. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]