On 07/03/13 16:18, geecxf wrote:
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.
FYI, OAuth2 module also supports SAML assertions as client credentials
now, it might offer another dimension to the whole story,
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.
Thanks for the above story,
IMHO, optionally supporting the metadata exchange can add to CXF's
already extensive SAML support, I hope Colm and Oli will support the
idea :-)
You mentioned earlier that using a JAX-WS endpoint + OpenSaml can offer
some initial support - may be you can start experimenting and drive the
process ?
Thanks, Sergey
--
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.
