I'm still confused about your use case. On the one hand you mention SAML SSO, 
OpenAM  which is for web application SSO and on the other hand you mention Web 
Services authentication. In both cases, the SAML metadata specification can be 
used to define the trust relationship in a standard way.

>>>
The SAML metadata specification describes a "standard" way to share this
kind of information between the relying party and the asserting party.
Technically speaking, you could come up with your own way of sharing that
information but SAML metadata makes life easier to share.
>>>
Agreed.

>>>
In a way this is similar to the FederationMetadata.xml file you exchange to
establish trust when using WS-Federation.
>>>
The WS-Federation specification recommends to use EntitiesDescriptor instead of 
FederationMetadata, as stated here:
http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223174943

But there are a few extensions as the SAML specification stack (core, binding, 
profile) has got a strong focus on Web Application SSO (not Web Services). 
OpenAM implements the SAML specification stack.

One important thing to note is that WS-Federation specification defines the use 
cases for Web Services communication (in combination with an STS) as well as 
Browser to Web Application communication (Passive Requestor Profile). The 
latter is already supported in the subproject Fediz of CXF including SAML 
Metadata support (see my link in my first mail).

There are more or less the following specifications relevant for SAML in 
combination with Web Services which are WS-Security SAML Token profile, 
WS-Trust, WS-SecurityPolicy and WS-Federation (no explicit dependency to a 
single security token format) where SAML Metadata specification can be used to 
define the trust relationships.

Which use case are you looking into where SAML metadata is used: Browser or Web 
Services?

Last but not least, I prefer to have a manual deployment step required in 
establishing the trust with the IDP/STS because otherwise, the IDP can just 
change the signing certificate and replace it at a latter stage by a 
self-signed certificate and all SP do still trust it.



------

Oliver Wulff

Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com

Talend Application Integration Division http://www.talend.com

________________________________________
From: geecxf [[email protected]]
Sent: 06 March 2013 22:59
To: [email protected]
Subject: Re: SAML metadata

FYI - the specification is here:

http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

If you want to see one implementation of this take a look at ForgeRock's
OpenAM.

In a way this is similar to the FederationMetadata.xml file you exchange to
establish trust when using WS-Federation.




--
View this message in context: 
http://cxf.547215.n5.nabble.com/SAML-metadata-tp5723816p5724197.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to