Clojurians Log v2

The Sun stays at the horizon?

Morning!

Good morning!

👋

Good Morning!

Good morning

Some of the great things about doing my commute to work on a stationary bike is that: 1. I can adjust the length of the commute 2. The weather is quite constant 3. Taking the subway instead is not an option

morning

Ah, @simongray. It reminds me that we were discussing SAML/OAuth/stuff on Friday. Here’s some general and unsolicited advice: At Ardoq the authorization code has always been something we’ve been scared to touch. Simply because, at the end of the day, it’s integration code (which makes it hard to test end to end), and to make things worse, it’s integration code which integrates to systems we don’t have access to. This means that any change done to this code has been done in the most defensive/intrusive manner, which, in my experience, tends to lead to quite messy code. Which means that over time, this code became scarier and scarier, and harder and harder to understand. So, my advice is, make sure this code is well tested, in a black-box kind of way, eg, understand the oauth/saml protocol, write a mock implementation of an oauth idp (to the best of your knowledge) and write tests that use the mock implementation to drive your oauth tests. Same for SAML. Also, take your time to make this code really pristine and understandable, since it will be with you for a long time, and the consequences of introducing errors in this code leads to customers not being logged in. At best.

@slipset thanks for the advice. I did code the whole thing up against a mock IdP (the same used in this example code: https://github.com/quephird/saml-test), so I guess I could write some kind of integration test involving a web driver and that IdP, if I can find the time. Anyway, to me that auth code isn’t all that scary right now, but I get that it definitely can become so if I revisit it after a long time. I definitely won’t have time to make a mock IdP myself this time around. My time is severely limited by budgetary constraints - that’s just how it is in academia. The thing is, in this job I’m kind of expected to be a one-man army working on several projects at multiple levels. So I do both ops stuff of existing systems, as well as everything - and by that I mean everything from setting up servers to doing research to system architecture to graphic design to writing all of the code - on new systems. And I work 3 projects at the same time + have my first child coming in a few weeks. It does have the advantage that I get to make all of the decisions and the advantage that I know all of the code intimately (since I wrote all of it). If I feel stressed about my current workload, I just close my eyes and think of what it was like working at my old job (the same huge government project @ordnungswidrig is on… unless he moved to some other project in the meantime).

You probably don’t have to go all the way to webdrivers and such. I’m assuming you have a rest api, (and probably using ring?) so your top-level handler is just a fn that expects a request-map and returns a response map. And for your saml code, this fn will be called twice. Once as a get (which will return a redirect response (where you can verify that you’ve got all the bits and bobs correctish (wrt to all the stuff that should be in such a redirect), and the second time it will be called as a post in which it should return an authenticated user or nil.

morning

morning

is there a clojure tool that will take a rest spec or WSDL and turn it into clojure.spec to do generative testing?

I've seen things that go the other way (spec to JSON schema for example)

I guess that’s more in the unit test-like area then. I’ll definitely try to test the pedestal interceptors independently 🙂

Do you want specs that you can reuse in clojure for some other purpose, or do you just want to generate test cases for a given WSDL? I'm certain I've seen tools for the latter in the java/GUIs world

@otfrom Maybe there are tools for JSON schema for generative testing already?

(a quick google confirms the hypothesis)

I'm mostly thinking about things like the SAML problem above and how to do the best testing on that. spec is supposed to be solving some of those problems

(so not an immediate requirement for me)

A major issue with all these SAML stuff is that it’s an open http endpoint with relatively complex payloads. So there’s a big chance of things going wrong/DDOS/buffer overflows etc. A private advice I received from a well-respected, security-oriented member of the Clojure community is to try and outsource all that stack entirely to a 3rd-party vendor, but not Auth0. Cognito is a safe choice.

Why not auth0? (At work we use Keycloak, fwiw)

I’d also like to hear about why not auth0.

Made a thing yesterday: https://github.com/borkdude/plsci 😎

I don’t recall much details, as far as I understood something is fundamentally “off” in the way Auth0 implement their “flow”, with respect to security.

But I’ve never used it nor do I have any context, but the advice was very emphatic 🙂

@borkdude that’s crazy 🙂

morning

At work we used to do openid connect using Keycloak but migrated to auth0 to not have to host the Keycloak servers

Works fine for us

Is keycloak onerous to administer? It’s one of the contenders together with CAS for a “service-like” approach.

Have started building an app on Keycloak, but am migrating to Auth0 in an early stadium now. I’d need to host and maintain my own keycloak including databases, redundant and failover-safe. This is obviously the most sensitive part of the infrastructure, and I can’t risk it going down or being insecure.

Might not be all rational, but running this myself scares me, there are so many connections and internet-facing-things

It’s based on Wildfly, so it’s heavy weight (although they are working on a lighter Quarkus alternative), but configuration is mainly based in a single, some-hundred-line json file, so infrastructure-as-code works quite well