[xenophonf]

Shibboleth is _the_ gold standard when it comes to SAML. I'm at the point where I don't recommend anything else, and I'm willing to help people deploy it (contact info in profile).

For this use case, they'd also need to configure JAAS.

[jtl999]

I'll give just Shibboleth a try later.

I've been thinking of writing my own SAML IdP in Python (since I have plenty of experience with the language) and I'm not naive to the various security things that can go wrong, but I'm no expert cryptographer either.

[xenophonf]

I'll join the chorus recommending against inventing the wheel, unless you're doing that to learn SAML in which case I say more power to you. You should look into the existing work done by Roland Hedberg, SUNET, and others on pysaml2, which is now part of the IdentityPython project:

https://idpy.org/

https://github.com/IdentityPython

That said, I can't think of anyone using pysaml2 to implement identity providers aside from SATOSA, an IdP proxy. Nearly everyone I know runs either Shibboleth or SimpleSAMLphp. I recommend you run Shibboleth because there's a whole litany of interoperability issues you _won't_ encounter if you do. (The same goes for SimpleSAMLphp, but I have less experience with it.)

The IdentityPython and Shibboleth projects have a lot of overlap in terms of membership, and if you want to meet them and connect to the research and education side of the federated IdM community, which drives a lot of the open source work, you should come to the Internet2 Technology Exchange this year and stay for ACAMP. It's a super smart bunch of people. You'll learn a lot.

[user5994461]

Not to be dismissive but better look for an alternative solution. The SAML spec is a beast, you can work on it for months, you will hardly get a few percents of it working.

If you're doing that for a small company, maybe try to get a Microsoft active directory instead. It's a lot easier to setup and maintain and everything does their best to integrate with it.

[xenophonf]

I realize it's a little late to say this, but AD FS is garbage. I've run AD FS both as an InCommon IdP and an InCommon SP, with both as full federation partners. While I solved the metadata consumption, attribute scope checking, and discovery UX issues, I encountered lots of little interoperability issues that required disabling request/assertion encryption or switching between SHA-1/SHA-256 on individual CP/RP trusts. Ultimately, we replaced the IdPs with Shibboleth and moved the SPs behind SATOSA, which works a LOT better.

[Freak_NL]

> but I'm no expert cryptographer either.

You don't have to be, as you would not implement any cryptographic algorithms (ciphers, hash methods) yourself. Solid experience with software security in general is a requirement of course.