Any resources to learn about Cross-domain Identity Management (SCIM)?
I am having trouble understanding this part too
Also did you check the SCIM video from the workshop? Here is the link if you have not https://www.youtube.com/watch?v=78CuvtW8KvI
Thank you trace, I will check it out
Hey @pratham10 , I would recommend to start from here: Understanding SCIM | Okta Developer
Adding SCIM to App Integrations: Add SCIM provisioning to app integrations | Okta
I also found this video helpful in addition to the workshop:
All the best
I find this article very useful: What is SCIM? | Okta
Also this basic knowledge understanding is good as well: SCIM Protocol | Okta Developer
Short video describing SCIM. At first I thought it was just auth so you can sign your user into multiple products. Example if you have a web app and iOS app. But now I’m seeing it’s more for managing your employee access across devices… Not sure I can use this for my hackathon idea then. Or does the later also apply?
Ok it seems like OpenID Connect (OIDC) would be example using google or apple for login. You have one login that can give you access to your app and other apps, and using 0Auth or Okta to do this would fulfill the hackathon criteria.
OpenID Connect Protocol.
Still trying to understand SCIM
Hello everyone! I came here looking for some teammates for the hackathon
@natalie @monishb or someone else?
You can find teammate in Devpost. You can state that you are looking for team members on Devpost in the “Participants” tab and read profiles of other people who also want to find team members and find someone that matches your skills. Then you can send email to the person to contact and set up team members
@natalie simply put SCIM is: Okta SCIM (System for Cross-domain Identity Management) is a protocol that allows for the automatic provisioning and deprovisioning of user accounts in cloud-based applications and services. It’s a standard way of communicating user identity information between identity providers (like Okta) and service providers (like SaaS applications).
Let’s try to understand this better with a small example:
Scenario: Company XYZ and G Suite Integration
Company XYZ uses Okta as their identity provider to manage employee access to various cloud-based applications. They also use G Suite (Google Workspace) for their email, documents, and collaboration needs.
Here’s how SCIM could be used in this scenario:
- New Employee Onboarding:
- When a new employee, John Doe, joins Company XYZ, HR creates an employee profile in Okta.
- Okta, using SCIM, automatically sends this user information to G Suite.
- John now has an active G Suite account with his Company XYZ credentials.
- Role Change:
- After a few months, John is promoted to a manager position. HR updates John’s role in Okta.
- Okta, through SCIM, sends the updated information to G Suite.
- John’s permissions in G Suite are adjusted accordingly, giving him access to additional resources.
- Employee Offboarding:
- Unfortunately, after a year, John decides to leave the company. HR deactivates John’s account in Okta.
- Okta, via SCIM, sends a deactivation request to G Suite.
- John’s access to G Suite services is immediately revoked, preventing any unauthorized access.
- Account Reactivation:
- Later on, Company XYZ decides to rehire John. HR reactivates John’s account in Okta.
- Okta, using SCIM, notifies G Suite about the reactivation.
- John’s G Suite account is reactivated with the same credentials.
Without SCIM, these processes would likely involve manual intervention, which can be time-consuming, error-prone, and potentially lead to security risks (e.g., forgetting to deactivate an account after an employee leaves).
With SCIM, the entire process is automated, ensuring that user information is consistently and accurately synchronized between Okta and G Suite, making it a powerful tool for streamlining user management in a multi-application environment.
Now you may ask where can I find readymade integrations which other products are providing with SCIM, you can find the entire list here: Okta Integration Network Catalog
Let me know if you have any more questions
Did you understand SCIM? If you have questions, feel free to ask
Hey just watched the tutorial here
Since an organization fetches all users through Okta, what happens if they accidentally selected a user that isn’t a part of their org? It seems like they would have the ability to deactivate the users account
Yes you can remove an user. The soft delete functionality, as mentioned in the blog
Thanks @monishb
In the case of GSuite, I’m assuming in database for the domain likely only contains the users with that same domain email.
So if the company manages their gsuite users. Then when they use Okta to fetch users, I’m assuming they only have access to fetch users of their domain.
I was thinking of a software that might have example has different organizations and each organization handles their own user.
In the case of SCIM, when you import users to manage in okta, should the fetch for users then only get that organization’s users, and have some filter such as domain? How is that possible if the get command doesnt take input? Perhaps these are already things that are part of SCIM and not deeply mentioned in the On Demand Workshophttps://regionalevents.okta.com/enterprisereadyworkshops (
Enterprise-Ready Workshop: Manage Users with SCIM)
In the tutorial the get users fetched all users ex users with email domain porter and whiterabbit.fake. But if I added whiterabbit users and deactivated the user I shouldn’t have that permission since they don’t belong to my organization. Therefore how does SCIM only ensure you can only manage your organizations users?
@natalie think of it as a cluster of orgs, one org mapping to a domain and like you said a specific gsuite profile. In GSuite, the user database likely contains only users with email addresses associated with that specific domain. When a company uses Okta to fetch users, they would typically only have access to fetch users within their own domain. The domain is a top-level source of truth here and would ideally map to a single Gsuite profile.
Now you may have a use case of multiple other entities within your main domain, that’s when user groups, entitlements and roles come into play, to granularize the kind and amount of access each user gets.
@natalie In the scenario you described, where you added a user with the domain “whiterabbit.fake” and deactivated them, it’s important to understand that SCIM itself does not enforce organizational permissions. Instead, it’s up to the implementation and configuration of the SCIM integration within Okta to handle permissions and access control.
If you want to ensure that only users within a specific organization can manage their own users through Okta using SCIM, you’ll need to configure Okta’s SCIM integration settings accordingly. This may involve setting up filters based on domain or other attributes to control which users are synchronized and managed through SCIM.
In other words, the responsibility for ensuring that only users from a specific organization can manage their own users lies with the configuration and settings within Okta’s SCIM integration, rather than with SCIM itself.
Thanks @monishb
Makes sense.
SCIM is just an agreed upon format so that any one who wants to integrate knows that there are these APIs they can use to get user and group/org data.
Therefore if a Saas offers SCIM, they are communicating that they can handle and allow permission management of users data. It’s up to their customers to decide if they want to implement it or not.