Topic: Anyone know a SAML expert?

[Mike]

We've got a SAML IdP tied into our old system using SimpleSAMLPHP that we are trying to tie into our new Python systems.  Unfortunately, there aren't that many Python IdP implementations and we are reaching the point where I don't think we have enough knowledge of SAML to implement it securely.  So, we are considering getting a contractor who does have the knowledge for a short term engagement.

[hans]

I remember it being a pain to work with. (back in my Java/Groovy days)

Which SAML provider did you go with? That might help determine what Python lib you might want to use if they have an implementation for you. If I remember ones like Auth0 had client libs available for most languages.

[Mike]

I remember it being a pain to work with. (back in my Java/Groovy days)

Understatement right there

Which SAML provider did you go with? That might help determine what Python lib you might want to use if they have an implementation for you. If I remember ones like Auth0 had client libs available for most languages.

We are the identity provider (IdP).  The service provider (SP) side is actually pretty easy and we have that done already.  The provider side is where the pain is.  Everyone wants to be a consumer but no-one wants to be the provider

We actually did look at using a 3rd party service but there cost is far too high.  I could almost employee a full-time programmer for the yearly cost.

[ober]

Yeah, we're implementing Auth0.  Not cheap, but worth it.  Of course our primary engineer left the company so we're looking for someone too.

[Mike]

Hmmm, did a quick review of Auth0 and their pricing seemed a lot better than what our guy reported.  The best I was seeing was $2 / user / month.  Even if I cull our database those that that could potentially use the system I'm still left with well over $100K (probably looking at 2 to 3 times that) a year in costs.  We are still well over Auth0's free tier but they seem much more reasonable.

[ober]

Keep in mind that Auth0 got aquired by Okta.  They claim that they're still going to operate separately.  Also, we got their pricing down quite a bit through negotiation, by like 25% or something.  But then again we're spending like $300k/year.

[Mike]

Yeah, I saw that after I contacted them.  But, if they'll do a contract then I'm less worried about it.  Fortunately, we are a 501(c)(3) so we can generally get a discount that way.

If you don't mind and can say: How many users and daily logins?  Or more to the point, what is the metric they are using to determine how much to charge you and how does that relate to the cost?

[ober]

They use MAU (monthly active users), API calls (Machine 2 Machine), and then any addon services like security or whatever else.  We also contract for a certain number of 'enterprise connections' which allows us to connect to our bigger clients' IDPs.

[ober]

Oh, and we contract for between 350K MAU, 1000 M2M, and 10 enterprise connections.  Although MAU for us is different this year.  Our actual MAU numbers are closer to 750K but not all of our platforms are converted to Auth0 yet.

[Mike]

Great, thanks for the information.  Using monthly active users might just work.  We have a decent number of accounts but only a small portion actually use the system.

[Mike]

Just had a call with them and yeah it looks real promising.  Since they use MAU instead of raw account numbers we easily fall within their cheaper plans.

I do need to think about some of non-production sites that have their own login.  I feel like they can be consolidated to one and then have another login for our actual test system.

Edit: Actually, it looks like not.  Did more research on our MAU count and we had 3 months in the last year that broken the limit for that cheaper tier.  Oh well, back to self hosted SAML.

[ober]

Ah, that sucks.  Auth0 is pretty cool.

[Mike]

Yeah.  I was kinda looking forward to making it someone else's problem and getting some of the nicer behavioral based security.  Hopefully we'll revisit in the future and reevaluate then.