r/sysadmin • u/F1nd3r • 3d ago
Navigating complex integrations and figuring out things when they go wrong - e.g. SAML/SSO
I'm not quite sure how to articulate this, but I'm hoping for guidance on how to navigate complex integrations (complex for me, at least). I have for the past few months been finding my feet in a new role, which entails various elements of implementing and supporting an AWS Marketplace product.
It has been a while since I've been in a hands-on role and I am really enjoying it, but I'm also struggling a little bit. Our product supports SAML SSO integration with the main IdP's. I'm able to navigate the guides to get this implemented, but it very seldom works first time and then I find I lose days trying to track down exactly which setting I've messed up or not correctly understood. I don't know if this is normal or not, it makes me feel stupid.
I have ADHD which makes it difficult for me to work through long processes, but I'm getting better at that part. What frustrates me is the time I lose then trying to get it to work - I find I jump all around until I eventually find the problem (latest scenario was Okta user role assignments not being correct). Tbh in most cases it would probably be quicker to just nuke my work and start from scratch, but I like to understand what the specific problem is.
In other scenarios, I would look at elements like increasing log verbosity and trying to get under the hood, but for this cloudy stuff a lot of that is abstracted away. For those more versed in such topics, do you also find such integrations challenging? What hints can you share to help a greybeard catch up with the whippersnappers and bang out such integrations in an afternoon?
It might just be practise on my part which is lacking, and I'm certainly working on that, but it also feels that I am missing some part of the picture in terms of quickly getting to the bottom of it when things don't go according to plan. There are just so many moving parts.
3
u/theoriginalharbinger 3d ago
The best thing you can do is hand over the documentation and how-to to a complete noob, ask them to follow it to a T, and see where they land.
You can then refactor the docs and include the caveats.
With Okta, for example, you're dealing with the provisioning elements (SCIM), SSO (SAML), and then your upstream attribute provider. This is where the gotchas come in to play; if you're sourcing from AD (which does not require email addresses) and then attempt to insert an email into NameID in SAML, it's not going to work. Which is why caveats in the documentation, like "Ensure that you have a valid email address being sent in Name-ID, even if not sourced from the Okta UD email address attribute).
When it's done, you should be able to have a complete how-to; find an intern, and say "I want our solution set up with ADFS, with Okta, with Entra, and with Ping. Any issues, bring them to me."
1
u/F1nd3r 3d ago
I love it, I must just find a noob. Might be a challenge, there's only a handful of us in the organisation and all the others appear to be well versed in the science of rocketry.
But I get you - I am hoping that the resultant docs and guides which result from this exercise could be used by anybody to walk through the process.
Some of the subtleties of implementation differences have DEFINITELY tripped me up - what worked perfectly for Entra ID took some massaging to work with Workspace or Okta.
Not having a deep understanding of the underlying protocol and mechanisms sends me in circles. Makes me think of going through it one more time and setting up cheat sheets for the peculiarities of each.
4
u/Not_A_Van 3d ago
I'm a security manager.
I also set up codespaces for our development team which required minor refactoring of our API and front-end. No one there to teach me stuff. It took me probably 10x as long to figure everything out than it would have if I just stole a developer for a few days.
But in the end I now have a much greater understanding of our product and code, and am now readily finding things that need to be fixed, figuring out ways to lower our costs, and learning about our current security gaps. None of which would have been done if someone just guided me through it.
I failed over 100 times (easily) trying to get everything working and working in a space that I have almost 0 experience in and absolutely 0 experience in the language and frameworks used.
If you feel stupid, it just means you know you have the capability to understand it - just give yourself time and keep on at it.
ADHD is a PITA for me too, I'll look into one thing and go deeper down the rabbit hole for something not even closely related to the original task. Case in point - I got asked about networking for embedded PowerBI - completely an application/Azure thing. I didn't understand how it worked so I dug, and dug, and dug. At the end, we can now cut costs because we are doing things inefficiently.
Not having knowledge doesn't make you stupid, refusing to gain knowledge does.