Hi everyone,
I work for a consulting firm and we're looking to bring on an Okta Technical Architect (Full delivery for enterprise clients). It's a client facing position and we're targeting about 85/HR on W2 (part time and full time available)
Requirements:
• Okta Design
• Consulting experience
• Okta certification (Certified Consultant ideally)
Would appreciate any referrals!
DM me please
Hey everyone! observation from working in authorization: Identity programs have been putting serious work into agent authentication over the last couple of years, service accounts done properly, OAuth scopes tightened, secret rotation, short-lived tokens. The authN side isn't fully solved (it never is) but it's where most of the effort has been going..
The part getting less air-time is what happens after the agent is authenticated, when it's acting on a workflow and something starts looking off. The default plan there is still "if it misbehaves, kill the agent."
That stops working the moment the agent is wired into something real. Pulling the switch creates a secondary incident, halted workflows, paused queues, downstream teams scrambling. So the agent keeps running at full access while the team figures out what's wrong, because the standard toolkit doesn't have a middle setting.
A colleague of mine was talking to a CISO about this and the framing that CISO used was dimmer switch, not kill switch. The dimmer lives in the authZ layer at runtime, which is the part identity stacks haven't extended into yet for non-human principals.
In practice the dimmer looks like read-only on certain data first. Sensitive tools dropped next. Higher approval thresholds for anything above a certain size. Each adjustment is reversible and logged. If the agent turns out to be fine, restrictions fade back. if not, you keep tightening until access is at zero, but you got there deliberately and with a record
mechanism isn't new - per-action policy enforcement at runtime has been around for years for human users. What's newer for AI agents specifically is wiring it to the agent's identity, current task, and intent at runtime, so you can narrow scope without redeploying or stopping the agent mid-task.
My team and I (work at Cerbos) wrote up the full framing here: https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance
Now i'm curious to know how identity programs you all are seeing / part of, are organizing this. Is agent authorization landing inside the iam team, security ops, the application teams, or sitting in no man's land between them? If you're open to sharing - please do!
Usual caveat, none of this replaces human review of policy. Tooling makes the revocation mechanical. Humans still own the call on where the boundaries should sit :)
TLDR I am hoping for book resources that can teach me about IAM. My goal is to use what I learn in my work and for certification.
In my job I stumbled into IAM. TBH I didn't even know there was a name for what I was doing until I went to a hacker convention in NYC, and somebody explained what it was.
Essentially, built off of programs similar to azure/ldap/fds I am building a custom program for users at my company to control who or what has access to THEIR apps they are building. This is in the wake of the company using a really shitty tool for a long time.
We kept complaining about the old tool for so long they finally said to me, you got the green light, build it.
Cool. I'm having fun with this project but the more we put into it the more security comes to mind.
So based on what I learned from the con I want to learn about IAM with the goal to help me with this project but it would also be nice to have a certification on top (like a 🍒)
I found an udemy that is up to date which is great but I work really well (and better) with text in books and not videos.
I am hoping for book resources that can teach me about IAM. My goal is to use what I learn in my work and for certification.
🐈
Hey everyone! I’m a Senior Backend/IAM Engineer at a large tech company with 10,000+ employees. I’ve been working with Golang for 8+ years, and for the last few years I’ve been focused mostly on IAM and security.
Our team builds and operates most of our internal IAM infrastructure, and all of our services are written in Go.
Some of the things we work on:
- employee identity lifecycle: onboarding, transfers, offboarding;
- automated access provisioning and revocation;
Active Directory and OpenLDAP;
- access reviews and least-privilege processes;
- Keycloak and Ory Hydra;
- OAuth 2.0, OIDC, SSO and 2FA;
- migrating our internal apps from Hydra to Keycloak.
I’m thinking about writing a few technical articles or maybe preparing a conference talk about real-world IAM engineering.
So I’m curious: what would you actually like to hear about? What IAM/security problems do you think aren’t discussed enough?
Happy to answer questions here too, as long as I can do so without sharing anything sensitive or company-specific.
Genuinely curious, because I keep going back and forth on this.
What stuck with me about the Hugging Face incident wasn't really the "AI escaped the sandbox" headline. It was the mechanics: a zero-day, stolen credentials, lateral movement, and exposed credentials on other services.
That's basically the playbook for a compromised privileged account.
The weird part is that the "user" wasn't a person. The model was able to improvise its way through the environment because the access was there and nothing stopped it early enough.
Then there’s another problem: I've seen research suggesting a large chunk of organizations still can't reliably distinguish agent activity from human activity in their logs. And depending on the research, non-human identities already outnumber human identities by a huge margin.
So I'm curious about what people are actually doing in production:Are you giving agents their own identities with scoped and just-in-time access?Or is it still mostly "give it a service account and move on"?Has anyone seriously audited which MCP servers, tools, APIs, and credentials their agents can reach?Did the Hugging Face incident lead to any real changes internally, or did it just become another security-slide topic for next quarter?
I'm not looking for a vendor pitch here. I'm genuinely trying to understand where the industry is.
Are teams actually operationalizing agent identity and access management yet, or are most of us still in the "we know this is going to become a problem" phase?
Hi everyone,
I'm working on an app that is going to be used on our university campus, and I'm having a hard time on how to use rbac to handle authorization on the app, cause it's being integrated with university sso for authentication, which also provides a Go backend with the roles of the authenticated user(could be a student, lecturer) during sign in, and I'm now wondering on whether I should integrate or merge those roles into my existing rbac flow which makes the app in sync with university system because in case a lecturer roles get updated or just totally neglect those roles and only depend on my existing rbac.
When building cloud applications, it's common to start by storing connection strings, passwords, API keys, or other credentials in configuration.
But what if your application could authenticate with Azure resources without managing those credentials at all?
That's where Azure Managed Identity comes in.
I put together a practical guide covering:
📖 https://geeksarray.com/blog/azure-for-dotnet-part-4-managed-identity
For developers working with Azure:
Do you use Managed Identity in your projects? If so, what has your experience been like?
Considering you have Entra as your Access Management solution and Okta Identity Governance or Sailpoint as your IGA, how will you architect the solution for long term .
Will you integrate all apps to your IGA solution (which also includes AD and Entra ID )
Or you provision to Entra and then let entra do all the processing.
But we wana do Access reviews, Role discovery of apps , jml
Entra right now is not fully capable of handling many governance tasks.
What direction you suggest ?
Himmelblau is gearing up for it's 4.0 release (scheduled for Aug 31st).
Among the new features:
* Cross-device passkey login using QR codes and Bluetooth
* Experimental native MFA for Keycloak and Okta
* Expanded OIDC account mapping and group/role access controls
* Faster, asynchronous and scheduled Intune compliance checks
* Authentication prompt localization across dozens of languages
https://github.com/himmelblau-idm/himmelblau
https://himmelblau-idm.org
(this is GPL3+ opensource community release, I know the website looks a little business-like, but it's just the community's homepage)
putting together a gap analysis for leadership and want to sanity check against what other teams run into, not just vendor talking points. our list so far: non-human identities with standing access nobody reviews, local accounts on apps outside the main IdP, agent/bot credentials that got provisioned fast during some AI pilot and never got cleaned up, and access reviews that only cover systems already wired into the IGA tool.
what's on your list that we're missing?
Like the title says, I am looking for a Ping platform engineer. This candidate needs to have expertise in implementing Ping Access and supporting onboarding of applications to Ping identity. Requirements are, Ping experience, active security clearance or the ability to obtain one and any of the IAT level 2 or higher certification.
When we first switched to the new IAM system, it was a bit of a struggle, and even after many years I still feel like the existing test environments aren’t always enough—especially when you want to experiment with a new configuration, integration, or use case as a proof of concept. Existing configurations can conflict with the changes you’re trying to test, and IAM setups aren’t always easy to reproduce and test locally.
How do you handle this in your teams, regardless of whether the IAM solution is SaaS or on-prem? Do you have a separate environment, process, or approach for running POCs and validating IAM changes before they reach higher environments?
I’m available for remote freelance opportunities in Identity & Access Management, Okta, and Active Directory.
I have experience supporting enterprise IAM environments and handling identity, access, authentication, provisioning, and directory-related operations.
Okta / IAM
Active Directory
IT Support
I can support Okta administration, Active Directory operations, IAM implementation and support, access management, application integrations, troubleshooting, automation, and day-to-day identity operations.
Availability: 10 to 20 hours per week
Engagement: Freelance, Contract or Ongoing
Location: India | Remote
If your team needs someone to support Okta, Active Directory, or broader IAM operations, feel free to comment or DM me.
My company is looking at more secure ways to handle communication and sensitive information, and Kibu is one of the options I've come across. Before considering something like this for a larger workspace, I'd like to hear from people who have experience with it.
I'm particularly interested in its identity verification and trust system. How advanced and reliable is the verification in practice? Have you ever run into issues with legitimate people being incorrectly verified or having trouble getting access?
Security is obviously the bigger concern. If you've used Kibu before how is it in a business setting?
Per their documentation, Sprout HR does not have native SCIM capabilities. I am looking to build out a custom API for SCIM purposes in Entra.
I have already built out the SSO portion in Entra, of course, with the vendor having to configure their end, but now I am looking to handle SCIM as well. anyone have some low-effort ideas or tips?
Putting together a video covering the most common interview questions in IAM, aiming for a mix that's useful whether you're a junior engineer prepping for your first IAM role or a senior consultant on the other side of the table.
If you've interviewed for an IAM role recently, what actually got asked? And if you've been on the interviewer side, what do you ask candidates that actually separates people who understand the concepts from people who've just memorized documentation?
Junior and senior perspectives both genuinely useful here, they tend to reveal very different things.
UPDATE: Video is made and posted in yt channel (link in my profile)