OK I'll explain from the start. I apologize for the length of what will follow but at least it will provide a solid foundation.
This specific use case I am concerned with is trying to provide a SAML based authentication and authorization layer using SAML assertions. A popular solution for providing token based auth to RESTful web services is to cram tokens into the authorization header and, while I would have preferred a more lightweight token format (e.g. JWT), the powers that be demanded SAML because it happens to be ubiquitous in their space. Fortunately (or unfortunately), we're not alone in trying this solution and as it turns out CXF does have a SAML interceptor that expects the assertion in authorization header of an HTTP request. Now we come to the question of: who issues these tokens? Because the solution has to support delegation of auth decisions to a third party we have to support federation with an external STS. So a client would have to first obtain a token (by unspecified means) from that STS then submit its request with token to the back-end web services. This about the time when a colleague started raving about SAML metadata. Initially, I objected to this requirement because I felt that trusting the certificate of the STS and a simple audience restriction check would do. However, my colleague was very adamant about this "feature" which I understood only inasmuch as I had previous experience with federationMetadata.xml which is king in the land of Microsoft STSes such as ADFS and Azure ACS. So we went back and forth and I was like "dude we don't need this feature and we don't have to adhere to every single SAML spec under the sun and some of those specs are really annoying too" to which he would respond "we NEED SAML metadata, let's use OpenAM because it's a gift from god" to which I was like "yeah OpenAM is pretty cool but it's overkill, we're already using CXF stuff and their SAML interceptor is easy to setup". blah blah blah you've probably had conversations like this... So I was like let's keep an open mind and I read up a little bit on SAML metadata (you know the drill: a little wikipedia, a little spec perusing, a little googling "I hate SAML") and finally I came to the conclusion that maybe SAML metadata is a good solution for bootstrapping trust. So I look around to see if CXF supports SAML metadata and it looks like it doesn't but we should be able to use OpenSAML to provide that feature later.... Hey why don't I just ask the CXF guys since they've been so awesome at helping me out so far? So I did. In conclusion. SAML metadata is pretty new to me. But I can see the value in this feature when trying to federate with an external STS just as I see the value in using FederationMetadata.xml vs the tedium of importing the STS certificate into a store, and making potentially many separate configuration changes to set up audience restrictions, trusted issuers, token decryption etc. I don't disagree with manual deployment. Although I would point out that even if the STS did change their certificate to a self-signed certificate, hopefully that doesn't mean that you automatically trust it. For example, if I import SAML metadata into ADFS the certificate is not implicitly trusted and in fact if it is a self-signed certificate ADFS will complain and not trust/issue tokens until I explicitly add that certificate in the trusted people certificate store. On the other hand if the STS switches to using another certificate issued by a trusted root, I should not have a problem with that. Here the metadata seems useful for communicating information about the STS in a single document, not to make certificate trust decisions for you. So that's my story and I want to thank those who took time to read it. I would appreciate any suggestions, constructive criticism, ideas, help etc. As I've stated my understanding of SAML metadata is limited at this point so I hope to learn from your responses. -- View this message in context: http://cxf.547215.n5.nabble.com/SAML-metadata-tp5723816p5724243.html Sent from the cxf-user mailing list archive at Nabble.com.
