description:"अपने identity provider से SnapOtter में users और groups को sync करने के लिए SCIM 2.0 provisioning सेट करें। Okta, Azure AD / Entra ID, और custom integrations को कवर करता है।"
SnapOtter स्वचालित user और group provisioning के लिए SCIM 2.0 (System for Cross-domain Identity Management) लागू करता है। आपका identity provider user accounts को स्वचालित रूप से बना, अपडेट, निष्क्रिय, और पुनः सक्रिय कर सकता है और group memberships को sync कर सकता है।
::: tip Enterprise feature
SCIM provisioning के लिए `scim` feature वाली एक **enterprise** license आवश्यक है। यह team plan पर उपलब्ध नहीं है। इस feature के बिना, सभी SCIM endpoints (discovery को छोड़कर) 403 लौटाते हैं।
:::
## Prerequisites {#prerequisites}
- एक चालू SnapOtter instance जो एक public URL पर पहुँच योग्य हो
- पूर्ण प्रभावी अनुमति सेट के साथ एक अंतर्निहित SnapOtter `admin` खाता। एक प्रत्यायोजित कस्टम भूमिका या एक व्यवस्थापक एपीआई कुंजी जिसमें कोई व्यवस्थापक अनुमति नहीं है, वैश्विक SCIM टोकन उत्पन्न या निरस्त नहीं कर सकता है।
`POST /api/v1/enterprise/scim/token` एक नया SCIM टोकन उत्पन्न करता है। क्योंकि टोकन पूरे इंस्टेंस में उपयोगकर्ताओं को प्रावधानित और परिवर्तित कर सकता है, इस एंडपॉइंट के लिए संपूर्ण प्रभावी व्यवस्थापक अनुमति सेट के साथ अंतर्निहित `admin` भूमिका की आवश्यकता होती है। `users:manage` को कस्टम भूमिका में रखना पर्याप्त नहीं है।
Token plaintext में ठीक एक बार लौटाया जाता है। SnapOtter केवल एक scrypt hash संग्रहीत करता है। यदि आप token खो देते हैं, तो उसे रद्द करें और एक नया जनरेट करें।
एक समय में केवल एक SCIM token सक्रिय रहता है। एक नया token जनरेट करने से पिछला token बदल जाता है।
लीगेसी अपरिवर्तित SCIM टोकन अस्वीकार कर दिए गए हैं। `so_scim_v2_...` टोकन जारी करने वाली रिलीज़ में अपग्रेड करने के बाद, एक नया टोकन जेनरेट करें और प्रावधान फिर से शुरू करने से पहले अपने पहचान प्रदाता को अपडेट करें।
| User | User account | Yes | Yes | Yes | Soft delete |
| Group | Team | Yes | Yes | Yes | Yes |
::: warning
SCIM Groups SnapOtter **teams** से मैप होते हैं, roles से नहीं। SCIM किसी user की role सेट नहीं कर सकता। SCIM के माध्यम से बनाए गए सभी users को `user` role सौंपी जाती है। किसी user की role बदलने के लिए, SnapOtter admin UI का उपयोग करें।
:::
## User operations {#user-operations}
### Create user {#create-user}
`POST /api/v1/scim/v2/Users`
`authProvider` को `scim` पर सेट करके और `user` role के साथ एक नया user account बनाता है। User को Default team में सौंपा जाता है। यदि `active``false` है, तो इसके बजाय role को `disabled` पर सेट किया जाता है।
आवश्यक attributes: `userName`. वैकल्पिक: `externalId`, `emails`, `active` (default `true`).
### List and filter users {#list-and-filter-users}
`GET /api/v1/scim/v2/Users`
users की एक paginated सूची लौटाता है। `startIndex` और `count` query parameters का समर्थन करता है (अधिकतम 200 results प्रति page)।
Filtering केवल इन attributes पर `eq` (equals) का समर्थन करती है:
-`userName eq "jane"`
-`externalId eq "ext-12345"`
अन्य filter operators और attributes HTTP 400 लौटाते हैं।
### Get user {#get-user}
`GET /api/v1/scim/v2/Users/:id`
किसी user को उसके SnapOtter user ID द्वारा एकल रूप में लौटाता है।
### Replace user {#replace-user}
`PUT /api/v1/scim/v2/Users/:id`
user के attributes को बदल देता है। `userName`, `externalId`, `emails`, और `active` का समर्थन करता है। Username परिवर्तनों को conflicts के लिए जाँचा जाता है (409 यदि नया username किसी अन्य user द्वारा लिया गया है)।
### Patch user {#patch-user}
`PATCH /api/v1/scim/v2/Users/:id`
SCIM PatchOp का उपयोग करके आंशिक अपडेट। समर्थित operations:
`name.formatted` और `displayName` paths संगतता के लिए स्वीकार किए जाते हैं लेकिन उनका कोई स्थायी प्रभाव नहीं होता (SnapOtter एक अलग display name संग्रहीत नहीं करता)।
Valueless `replace` operations (जहाँ value एक object है जिसमें `path` नहीं है) भी समर्थित हैं, keys `userName`, `externalId`, `emails`, और `active` के साथ।
### Deactivate user (soft delete) {#deactivate-user-soft-delete}
`DELETE /api/v1/scim/v2/Users/:id`
SnapOtter SCIM के माध्यम से users को hard-delete नहीं करता। इसके बजाय, DELETE एक soft deactivation करता है:
1. user की role उसके वर्तमान मान (जैसे `editor`) से `disabled:editor` में बदल दी जाती है, मूल role को संरक्षित करते हुए।
2. user का password साफ़ कर दिया जाता है।
3. सभी सक्रिय sessions रद्द कर दिए जाते हैं।
4. सभी API keys रद्द कर दी जाती हैं।
user अब log in नहीं कर सकता या किसी API key का उपयोग नहीं कर सकता। उनका data (files, history) बरकरार रहता है।
### Reactivate user {#reactivate-user}
पहले से निष्क्रिय किए गए user को पुनः सक्रिय करने के लिए, `active: true` के साथ एक `PUT` या `PATCH` request भेजें। SnapOtter deactivation से पहले की मूल role को पुनर्स्थापित करता है (जैसे `disabled:editor` फिर से `editor` बन जाता है)। यदि मूल role निर्धारित नहीं की जा सकती, तो यह `user` पर वापस आ जाती है।
::: details उदाहरण: PATCH के माध्यम से deactivate और reactivate
- **Secret Token**: ऊपर जनरेट किया गया SCIM bearer token
4.**Test Connection** क्लिक करें, फिर **Save** क्लिक करें।
5.**Mappings** के तहत, user और group attribute mappings को configure करें। Defaults आमतौर पर काम करते हैं, लेकिन सत्यापित करें कि `userName` इच्छानुसार `userPrincipalName` या `mail` पर मैप होता है।
6.**Provisioning Status** को **On** पर सेट करें और सहेजें।
Azure एक निश्चित sync cycle पर users और groups को provision करता है (आमतौर पर हर 40 मिनट में)।
## Discovery endpoints {#discovery-endpoints}
ये तीन endpoints authentication के बिना उपलब्ध हैं और SCIM server की क्षमताओं का वर्णन करते हैं:
| Endpoint | Description |
|---|---|
| `GET /api/v1/scim/v2/ServiceProviderConfig` | Server capabilities और supported features |
| `GET /api/v1/scim/v2/Schemas` | User और Group schema definitions |
| `GET /api/v1/scim/v2/ResourceTypes` | उपलब्ध resource types (User, Group) |
`ServiceProviderConfig` इन क्षमताओं का विज्ञापन करता है:
- **Filtering**: केवल `eq` operator समर्थित है। Complex filters, `and`/`or` operators, `co` (contains), और `sw` (starts with) लागू नहीं किए गए हैं।
- **Bulk operations**: समर्थित नहीं।
- **Sort और ETag**: समर्थित नहीं।
- **Roles**: SCIM SnapOtter roles सौंप नहीं सकता। सभी provisioned users को `user` role मिलती है।
- **MAX_USERS**: SCIM user creation पर `MAX_USERS` environment variable सीमा लागू नहीं होती। यदि आपको user counts सीमित करने की आवश्यकता है, तो अपने IdP में assignments प्रबंधित करें।
- **One token**: एक समय में केवल एक SCIM token सक्रिय हो सकता है। यदि कई IdPs को SCIM access की आवश्यकता है, तो उन्हें token साझा करना होगा।
- **Groups are teams**: SCIM Groups teams के अनुरूप होते हैं, roles या permission groups के नहीं।
## Troubleshooting {#troubleshooting}
### 403 "SCIM provisioning requires an enterprise license with the scim feature" {#_403-scim-provisioning-requires-an-enterprise-license-with-the-scim-feature}
आपकी license में `scim` feature शामिल नहीं है, या कोई license configure नहीं है। SCIM के लिए एक enterprise plan license आवश्यक है। सत्यापित करें कि `SNAPOTTER_LICENSE_KEY` सेट है और license में `scim` feature शामिल है।
टोकन विकृत है, सेवानिवृत्त अपरिवर्तित प्रारूप का उपयोग करता है, या संग्रहीत हैश से मेल नहीं खाता है। एक मौजूदा `so_scim_v2_...` टोकन जेनरेट करें और अपने IdP की प्रोविजनिंग सेटिंग्स में टोकन को अपडेट करें।
समान username वाला एक user पहले से मौजूद है। यह तब हो सकता है जब कोई IdP किसी विफल create को पुनः प्रयास करता है। SnapOtter admin panel में डुप्लिकेट usernames की जाँच करें।
IdP प्रति मिनट 1000 से अधिक requests भेज रहा है। यह आमतौर पर एक बड़े प्रारंभिक sync के दौरान होता है। अधिकांश IdPs rate limit window रीसेट होने के बाद स्वचालित रूप से पुनः प्रयास करते हैं। यदि समस्या बनी रहती है, तो अपने IdP का provisioning sync interval जाँचें।
### Users deprovisioned but not removed from the UI {#users-deprovisioned-but-not-removed-from-the-ui}
SCIM DELETE एक soft deactivation है। निष्क्रिय किए गए users अभी भी admin user सूची में disabled status के साथ दिखाई देते हैं। यह डिज़ाइन के अनुसार है ताकि उनका data संरक्षित रहे। उनकी role `disabled:<original-role>` के रूप में दिखाई देती है।
