OpenSAML3.3 Correct way to read (adfs) FederationService.xml?

[Cantor, Scott]

On 5/24/17, 10:08 AM, "dev on behalf of Rob Audenaerde" <dev-bounces at shibboleth.net on behalf of rob.audenaerde at gmail.com> wrote:

> Thanks for your advice, I'm really not trying to reinvent the wheel, so if you have easier solutions, they are most welcome!

You're doing basically the platonic definition of reinventing the wheel and I'm just trying to urge you not to because implementing federated identity is very, very difficult to do well and there are dozens of horrible implementations out there already. I don't know your situation, but if you were, for example, a vendor that my customers would have to work with later, you would end up with one of those SAML implementations that cause us so many problems because of poor metadata support, questionable key management, limited SAML features, etc.

That's not because you don't want to do a good job but because you won't be able to (there's nothing to teach you how) and because you'll inevitably decide you don't need certain things out of expediency. You should simply use a full featured choice to start with, or at least isolate the application enough from what you do use so that if you needed to plug in a more full featured choice later you can do it.

> I'm not planning to implement SAML myself, rather I intent to re-use as much as possible from OpenSAML to implement
> WebSSO. 

OpenSAML is a low level library for building SAML implementations. It is *not* one itself. OpenSSL, for example, is a TLS implementation. You can pretty reasonably implement TLS in an application by just using it. You can't do that with OpenSAML. There are thousands and thousands of lines of code in both the IdP and SP in Shibboleth that aren't in OpenSAML.

> Maybe I am misunderstanding things, as it is all kind of new to me. The security is handled by Wicket, I just need the
> authentication part.  

If you have a web app, you do not need authentication. The web server handles authentication, and you consume it via REMOTE_USER or if you want to do more advanced things with attributes by reading request variables. You need to do less work, not more.

I suspect you aren't reimplementing sessions, right? This is much worse than doing that.

> What would you suggest? I want the configuration as simple as possible, preferable without bringing in big libraries, and being
> able to do configuration in code as much as possible.  And I would like to understand what is happening, so in case something
> doesn't work, I might be able to fix it :)

I suggest you pick an existing SAML implementation to use. No matter how much worse it seems or how much "extra" configuration it involves. Later on you'll want to swap it out for something different, and later on you'll want to swap *that* out for something different. If not you, then the guy stuck with it later will.

You mentioned OpenAM, so frankly that's pretty much fine. Not great, but not terrible certainly.

-- Scott