diff --git a/docs/docs/apis/openidoauth/endpoints.md b/docs/docs/apis/openidoauth/endpoints.md index 0b2a4b4417..11fb875df4 100644 --- a/docs/docs/apis/openidoauth/endpoints.md +++ b/docs/docs/apis/openidoauth/endpoints.md @@ -227,7 +227,7 @@ Send a client assertion as JWT for us to validate the signature against the regi | ---------- | ----------------------------------------------------------------------------------------------------------------------------- | | grant_type | Must be `urn:ietf:params:oauth:grant-type:jwt-bearer` | | assertion | JWT built and signed according to [Using JWTs for Authorization Grants](grant-types#using-jwts-as-authorization-grants) | -| scope | [Scopes](Scopes) you would like to request from ZITADEL. Scopes are space delimited, e.g. `openid email profile` | +| scope | [Scopes](scopes) you would like to request from ZITADEL. Scopes are space delimited, e.g. `openid email profile` | ```BASH curl --request POST \ @@ -250,7 +250,7 @@ curl --request POST \ ### Refresh Token Grant To request a new `access_token` without user interaction, you can use the `refresh_token` grant. -See [offline_access Scope](Scopes#standard-scopes) for how to request a `refresh_token` in the authorization request. +See [offline_access Scope](scopes#standard-scopes) for how to request a `refresh_token` in the authorization request. #### Required request Parameters @@ -258,7 +258,7 @@ See [offline_access Scope](Scopes#standard-scopes) for how to request a `refresh | ------------- | -------------------------------------------------------------------------------------------- | | grant_type | Must be `refresh_token` | | refresh_token | The refresh_token previously issued in the last authorization_code or refresh_token request. | -| scope | [Scopes](Scopes) you would like to request from ZITADEL for the new access_token. Must be a subset of the scope originally requested by the corresponding auth request. When omitted, the scopes requested by the original auth request will be reused. Scopes are space delimited, e.g. `openid email profile` | +| scope | [Scopes](scopes) you would like to request from ZITADEL for the new access_token. Must be a subset of the scope originally requested by the corresponding auth request. When omitted, the scopes requested by the original auth request will be reused. Scopes are space delimited, e.g. `openid email profile` | Depending on your authorization method you will have to provide additional parameters or headers: diff --git a/docs/docs/apis/proto/management.md b/docs/docs/apis/proto/management.md index 0c5dbaa08d..1b6a79e531 100644 --- a/docs/docs/apis/proto/management.md +++ b/docs/docs/apis/proto/management.md @@ -2994,7 +2994,7 @@ This is an empty request | Field | Type | Description | Validation | | ----- | ---- | ----------- | ----------- | | primary_color | string | - | string.max_len: 50
| -| hide_login_name_suffix | bool | hides the org suffix on the login form if the scope \"urn:zitadel:iam:org:domain:primary:{domainname}\" is set. Details about this scope in https://docs.zitadel.com/concepts#Reserved_Scopes | | +| hide_login_name_suffix | bool | hides the org suffix on the login form if the scope \"urn:zitadel:iam:org:domain:primary:{domainname}\" is set. Details about this [scope in](../openidoauth/scopes) | | | warn_color | string | - | string.max_len: 50
| | background_color | string | - | string.max_len: 50
| | font_color | string | - | string.max_len: 50
| diff --git a/docs/docs/apis/proto/policy.md b/docs/docs/apis/proto/policy.md index 026836f72f..aca3a0d755 100644 --- a/docs/docs/apis/proto/policy.md +++ b/docs/docs/apis/proto/policy.md @@ -33,7 +33,7 @@ title: zitadel/policy.proto | details | zitadel.v1.ObjectDetails | - | | | primary_color | string | hex value for primary color | | | is_default | bool | defines if the organisation's admin changed the policy | | -| hide_login_name_suffix | bool | hides the org suffix on the login form if the scope \"urn:zitadel:iam:org:domain:primary:{domainname}\" is set. Details about this scope in https://docs.zitadel.com/concepts#Reserved_Scopes | | +| hide_login_name_suffix | bool | hides the org suffix on the login form if the scope \"urn:zitadel:iam:org:domain:primary:{domainname}\" is set. Details about this [scope in](../openidoauth/scopes) | | | warn_color | string | hex value for secondary color | | | background_color | string | hex value for background color | | | font_color | string | hex value for font color | | diff --git a/docs/docs/examples/login/react.md b/docs/docs/examples/login/react.md index 6f9efc546d..99e0a9c397 100644 --- a/docs/docs/examples/login/react.md +++ b/docs/docs/examples/login/react.md @@ -11,7 +11,7 @@ At the end of the guide you should have an application able to login a user and Before we can start building our application we have to do a few configuration steps in ZITADEL Console. You will need to provide some information about your app. We recommend creating a new app to start from scratch. Navigate to your Project and add a new application at the top of the page. -Select User Agent and continue. More about the different app types can you find [here](https://docs.zitadel.com/docs/guides/authorization/oauth-recommended-flows#different-client-profiles). +Select User Agent and continue. More about the different app types can you find [here](../../guides/integrate/oauth-recommended-flows#different-client-profiles). We recommend that you use [Authorization Code](../../apis/openidoauth/grant-types#authorization-code) in combination with [Proof Key for Code Exchange](../../apis/openidoauth/grant-types#proof-key-for-code-exchange) for all web applications. ### Redirect URLs diff --git a/docs/docs/guides/integrate/access-zitadel-apis.md b/docs/docs/guides/integrate/access-zitadel-apis.md index abcba8644f..21ff8f25b2 100644 --- a/docs/docs/guides/integrate/access-zitadel-apis.md +++ b/docs/docs/guides/integrate/access-zitadel-apis.md @@ -2,32 +2,6 @@ title: Access ZITADEL APIs --- - - - - - - - - - - - - - -
DescriptionLearn how to authorize Service Users to access ZITADEL APIs.
Learning Outcomes - In this module you will: -
    -
  • Grant a Service User for ZITADEL
    • -
  • Authorize a Service User with JWT signed with your private key
    • -
-
Prerequisites - -
- :::note This guide focuses on the Admin, Auth and Management APIs. To access the ZITADEL System API, please checkout [this guide](./access-zitadel-system-api). ::: @@ -44,7 +18,7 @@ ZITADEL Managers are Users who have permission to manage ZITADEL itself. There a On each level we have some different Roles. Here you can find more about the different roles: [ZITADEL Manager Roles](../../concepts/structure/managers.md) -## Exercise: Add ORG_OWNER to Service User +## Add ORG_OWNER to Service User Make sure you have a Service User with a Key. (For more detailed informations about creating a service user go to [Service User](serviceusers.md)) @@ -96,31 +70,6 @@ Content-Type: application/json ``` With this token you are allowed to access the [ZITADEL APIs](../../apis/introduction) . -## Knowledge Check - - -* Managers are used for all users to get authorizations for all projects? - - [ ] yes - - [ ] no -* You need the ZITADEL Project Id in your audience and can access this with a custom scope? - - [ ] yes - - [ ] no - - -
- - Solutions - - - -* Managers are used for all users to get authorizations for all projects? - - [ ] yes - - [x] no (Managers are only used to grant users for ZITADEL) -* You need the ZITADEL Project Id in your audience and can access this with a custom scope? - - [x] yes - - [ ] no - -
## Summary @@ -128,7 +77,6 @@ With this token you are allowed to access the [ZITADEL APIs](../../apis/introduc * Because there is no interactive logon, you need to use a JWT signed with your private key to authorize the user * With a custom scope (`urn:zitadel:iam:org:project:id:{projectid}:aud`) you can access ZITADEL APIs - Where to go from here: * [ZITADEL API Documentation](../../apis/introduction) diff --git a/docs/docs/guides/integrate/identity-brokering.md b/docs/docs/guides/integrate/identity-brokering.md index 2e8748a288..882310033d 100644 --- a/docs/docs/guides/integrate/identity-brokering.md +++ b/docs/docs/guides/integrate/identity-brokering.md @@ -2,32 +2,6 @@ title: Identity Brokering --- - - - - - - - - - - - - - -
DescriptionLearn about identity brokering/federation and how to add an external identity provider to authenticate your users.
Learning Outcomes - In this module you will: -
    -
  • Learn about Identity Providers
    • -
  • Add a new identity provider
    • -
  • Example with Google Login
    • -
-
Prerequisites - -
- ## What is Identity Brokering and Federated Identities? Federated identity management is an arrangement built upon the trust between two or more domains. Users of these domains are allowed to access applications and services using the same identity. @@ -43,9 +17,9 @@ Because Google is registered as trusted identity provider the user will be able ![Identity Brokering](/img/guides/identity_brokering.png) -## Exercise: Register an external identity provider +## Register an external identity provider -In this exercise we will add a new Google identity provider to federate identities with ZITADEL. +In this step we will add a new Google identity provider to federate identities with ZITADEL. ### 1. Create new OIDC Client @@ -58,7 +32,7 @@ In this exercise we will add a new Google identity provider to federate identiti Google Example: -1. Go to the Google Gloud Platform and choose youre project: +1. Go to the Google Cloud Platform and choose your project: 2. Click on "+ CREATE CREDENTIALS" and choose "OAuth client ID" 3. Choose Web application as Application type and give a name 4. Add the redirect uris @@ -74,7 +48,7 @@ The login policy can be configured on two levels. Once as default on the instanc This case describes how to change it on the organization. 1. Go to your organization settings by clicking on "Organization" in the menu -2. Modify your login policy in the menu "Login Behaviour and Security" +2. Modify your login policy in the menu "Login Behavior and Security" ![Add custom login policy](/img/console_org_custom_login_policy.gif) @@ -93,7 +67,7 @@ This case describes how to change it on the organization. ![Configure identity provider](/img/console_org_identity_provider.gif) ### 4. Send the primary domain scope on the authorization request -ZITADEL will show a set of identity providers by default. This configuration can be changed by users with the [manager role] (https://docs.zitadel.com/docs/concepts/zitadel/objects/managers) `IAM_OWNER`. +ZITADEL will show a set of identity providers by default. This configuration can be changed by users with the [manager role](../../concepts/structure/managers) `IAM_OWNER`. An organization's login settings will be shown @@ -103,9 +77,7 @@ To get your own configuration you will have to send the [primary domain scope](. The primary domain scope will restrict the login to your organization, so only users of your own organization will be able to login, also your branding and policies will trigger. :::note - You need to create your own auth request with your applications parameters. Please see the docs to construct an [Auth Request](../../guides/integrate/login-users#auth-request). - ::: Your user will now be able to choose Google for login instead of username/password or mfa. diff --git a/docs/docs/guides/integrate/oauth-recommended-flows.md b/docs/docs/guides/integrate/oauth-recommended-flows.md index f0134e1d91..6db2f7de00 100644 --- a/docs/docs/guides/integrate/oauth-recommended-flows.md +++ b/docs/docs/guides/integrate/oauth-recommended-flows.md @@ -56,7 +56,7 @@ So what do we want to achieve with delegated authentication? * Instead of sending around the user’s credentials * Clients may access protected resources with an **access token** that is only valid for specific scope and limited lifetime (OAuth 2.x) - * Users have to **authorize** applications to access certain [**scopes**](https://docs.zitadel.com/architecture#Scopes) (eg, email address or custom roles). Applications can request [**claims**](https://docs.zitadel.com/architecture#Claims) (key:value pairs, eg email address) for the authorized scopes with the access token or ID token from ZITADEL + * Users have to **authorize** applications to access certain [**scopes**](../../apis/openidoauth/scopes) (eg, email address or custom roles). Applications can request [**claims**](../../apis/openidoauth/claims) (key:value pairs, eg email address) for the authorized scopes with the access token or ID token from ZITADEL * Access tokens are bearer tokens, meaning that possession of the token provides access to a resource. But the tokens expire frequently and the application must request a new access token via **refresh token** or the user must reauthenticate ![Overview federated identities](/img/guides/consulting_federated_identities_basics.png) @@ -115,7 +115,7 @@ If you don’t have any technical limitations, you should favor the flow Authori We recommend using **“JWT bearer token with private key”** ([RFC7523](https://tools.ietf.org/html/rfc7523)) for Machine-to-Machine clients. -What this means is that you have to send an JWT token, containing the [standard claims for access tokens](https://docs.zitadel.com/architecture#Claims) and that is signed with your private key, to the token endpoint to request the access token. We will see how this works in another module about Service Accounts. +What this means is that you have to send an JWT token, containing the [standard claims for access tokens](../../apis/openidoauth/claims) and that is signed with your private key, to the token endpoint to request the access token. We will see how this works in another module about Service Accounts. If you don’t have any technical limitations, you should prefer this method over other methods. @@ -123,35 +123,6 @@ A JWT with a private key can also be used with client profile web to further enh In case you need alternative flows and their advantages and drawbacks, there will be a module to outline more methods and our recommended fallback strategy per client profile that are available in ZITADEL. -## Knowledge Check (3) - -* With federated identities the user sends credentials to the server holding the protected resource - - [ ] yes - - [ ] no -* ZITADEL will discover your client profile automatically and set the correct flow - - [ ] yes - - [ ] no -* When working with APIs / machine-to-machine communication its recommended to exchange a JWT that is singed with your private key for an access token - - [ ] yes - - [ ] no - -
- - Solutions - - -* With federated identities the user sends credentials to the server holding the protected resource - - [ ] yes - - [x] no (Users are authenticated against a centralized IDP, only access tokens are send to the requested resources) -* ZITADEL will discover your client profile automatically and set the correct flow - - [ ] yes - - [x] no (ZITADEL does not make any assumptions about your application’s requirements) -* When working with APIs / machine-to-machine communication its recommended to exchange a JWT that is singed with your private key for an access token - - [x] yes - - [ ] no - -
- ## Summary (3) * Federated Identities solve key problems and challenges with traditional server-client architecture @@ -159,7 +130,7 @@ In case you need alternative flows and their advantages and drawbacks, there wil * “JWT bearer token with private key” for Machine-to-Machine clients * There are alternative flows and fallback strategies supported by ZITADEL, if these flows are technically not possible -Where to go from here +### Where to go from here * Applications * Service Accounts diff --git a/docs/docs/guides/integrate/serviceusers.md b/docs/docs/guides/integrate/serviceusers.md index 48ac472f99..c0a28408b5 100644 --- a/docs/docs/guides/integrate/serviceusers.md +++ b/docs/docs/guides/integrate/serviceusers.md @@ -2,38 +2,11 @@ title: Service Users --- - - - - - - - - - - - - - -
DescriptionLearn the basics about ZITADEL Service Users, how to set them up and authorize with ZITADEL.
Learning Outcomes - In this module you will: -
    -
  • Learn about Service Users
    • -
  • Create a Service User in ZITADEL Console
    • -
  • Authorize a Service User with JWT signed with your private key
    • -
-
Prerequisites - -
- - import UserDescription from '../../concepts/structure/_user_description.mdx'; -## Exercise: Create a Service User +## Create a Service User 1. Navigate to Service Users 2. Click on **New** @@ -53,9 +26,9 @@ You need to follow these steps to authenticate a service user and receive a acce With this token you can make subsequent requests, just like a human user. -## Exercise: Get an access token +## Get an access token -In this exercise we will authenticate a service user and receive an access_token to use against a API. +In this step we will authenticate a service user and receive an access_token to use against a API. > **Information:** Are you stuck? Don't hesitate to reach out to us on [Github Discussions](https://github.com/zitadel/zitadel/discussions) or [contact us](https://zitadel.com/contact/) privately. @@ -145,7 +118,7 @@ Content-Type: application/json ### 4. Verify that you have a valid access token -For this example let's call the userinfo endpoint to verfiy that our access token works. +For this example let's call the userinfo endpoint to verify that our access token works. ```bash curl --request POST \ @@ -167,35 +140,6 @@ Content-Type: application/json } ``` -## Knowledge Check - -* To secure backend APIs you can request an API key via ZITADEL's console - - [ ] yes - - [ ] no -* The JWT header must contain a property `kid` with the value of the key ID - - [ ] yes - - [ ] no -* After generating a key for your service user, you must download the public key and sign your JWT with the public key - - [ ] yes - - [ ] no - -
- - Solutions - - -* To secure backend APIs you can request an API key via ZITADEL's console - - [ ] yes - - [x] no (We use **“JWT bearer token with private key”**, [RFC7523](https://tools.ietf.org/html/rfc7523)) -* The JWT header must contain a property `kid` with the value of the key ID - - [x] yes - - [ ] no -* After generating a key for your service user, you must download the public key and sign your JWT with the public key - - [ ] yes - - [x] no (The json file contains the private key. Handle with care.) - -
- ## Summary * With service users you can secure machine-to-machine communication diff --git a/docs/docs/guides/manage/console/organizations.mdx b/docs/docs/guides/manage/console/organizations.mdx index 8c62438f4c..356c493ce8 100644 --- a/docs/docs/guides/manage/console/organizations.mdx +++ b/docs/docs/guides/manage/console/organizations.mdx @@ -11,7 +11,7 @@ import Column from '../../../../src/components/column'; There are several more modules in our documentation to go into more detail regarding organization management, projects, clients, and users. But first let’s create a new organization and verify your domain name. -## Exercise - Create a new organization +## Create a new organization To create a new organization login to your ZITADEL instance ({your-domain}-{random string}.zitadel.cloud or your custom domain). Click the organization drop down in the name in the upper left corner in the header, and then select “New organization”. diff --git a/docs/docs/guides/manage/customize/branding.md b/docs/docs/guides/manage/customize/branding.md index 656a02e9cb..f2b3368b01 100644 --- a/docs/docs/guides/manage/customize/branding.md +++ b/docs/docs/guides/manage/customize/branding.md @@ -8,6 +8,7 @@ The second possibility is to configure it on each organization. This guide will For this head over to the Branding Setting on your Organization Page. ## How it works + You are able to customize the light and a dark mode separately. All your changes will be shown in the preview window on the right side. As soon as you are happy with your configuration click the "Apply configuration" button. @@ -18,49 +19,52 @@ After this your settings will trigger in your system. The login and the emails w ![Private Labeling](/img/console_private_labeling.png) ### Logo + Upload your logo for the chosen theme, as soon as it is uploaded the preview on the right side of the screen should show it. ### Colors + In the next part you can configure your colors. Background colour is self-explanatory, the primary color will be used for buttons, links and some highlights. The warn color is used for all the error messages and warnings and the font colour for texts. ### Font + Last step to apply to your branding is the font upload. The best way is to upload a ttf file after a successful upload you will see it in the font part, but not in the preview. ### Advanced Settings + In the advanced behavior you can choose if the loginname suffix (domain e.g road.runner@acme.caos.ch) should be shown in the loginname screen or not and if the “ZITADEL watermark” should be hidden. ## Trigger the private labeling for the login + If you like to trigger your settings for your applications you have different possibilities. ### 1. Primary Domain Scope -Send a [primary domain scope](https://docs.zitadel.com/docs/apis/openidoauth/scopes#reserved-scopes) with your [authorization request](https://docs.zitadel.com/docs/guides/authentication/login-users/#auth-request) to trigger your organization. + +Send a [primary domain scope](../../../apis/openidoauth/scopes) with your [authorization request](../../integrate/login-users#auth-request) to trigger your organization. The primary domain scope will restrict the login to your organization, so only users of your own organization will be able to login. See the following link as an example. Users will be able to register and login to the organization that verified the @caos.ch domain only. + ``` https://{your_domain.zitadel.cloud}/oauth/v2/authorize?client_id=69234247558357051%40zitadel&scope=openid%20profile%20urn%3Azitadel%3Aiam%3Aorg%3Adomain%3Aprimary%3Acaos.ch&redirect_uri=https%3A%2F%2Fconsole.zitadel.cloud%2Fauth%2Fcallback&state=testd&response_type=code&nonce=test&code_challenge=UY30LKMy4bZFwF7Oyk6BpJemzVblLRf0qmFT8rskUW0 ``` :::info - Make sure to replace the domain `caos.ch` with your own domain to trigger the correct branding. - ::: :::caution - -This example uses the ZITADEL Cloud Application for demonstration. You need to create your own auth request with your applications parameters. Please see the docs to construct an [Auth Request](https://docs.zitadel.com/docs/guides/authentication/login-users/#auth-request). - +This example uses the ZITADEL Cloud Application for demonstration. You need to create your own auth request with your applications parameters. Please see the docs to construct an [Auth Request]../integrate/login-users#auth-request). ::: - - ### 2. Setting on your Project + Set the private labeling setting on your project to define which branding should trigger. ## Reset to default + If you don't like your customization anymore click the "reset policy" button. All your settings will be removed and the default settings of the system will trigger. diff --git a/docs/docs/guides/manage/customize/user-metadata.md b/docs/docs/guides/manage/customize/user-metadata.md index df93df7d38..143b06f724 100644 --- a/docs/docs/guides/manage/customize/user-metadata.md +++ b/docs/docs/guides/manage/customize/user-metadata.md @@ -17,14 +17,14 @@ Typical examples for user metadata include: ### Create a new client -- Create a new [web application](https://docs.zitadel.com/docs/guides/start/applications#web) +- Create a new [web application](../console/applications#web) - Use Code-Flow - In this example we will use `http://localhost` as redirect url - Make sure to note the client secret ### Add metadata to a user -- [Add metadata](https://docs.zitadel.com/docs/manuals/user-profile#metadata) to a user +- [Add metadata](../../../manuals/user-profile#metadata) to a user - Make sure you will use this user to login during later steps ## Requesting a token @@ -47,7 +47,7 @@ export ZITADEL_DOMAIN="https://...asd.zitadel.cloud" -Grab zitadel-tools to create the [required string](https://docs.zitadel.com/docs/apis/openidoauth/authn-methods#client-secret-basic) for Basic authentication: +Grab zitadel-tools to create the [required string](../../../apis/openidoauth/authn-methods#client-secret-basic) for Basic authentication: ```bash git clone git@github.com:zitadel/zitadel-tools.git @@ -93,7 +93,7 @@ Export the result to the environment variable `BASIC_AUTH`. -You need to create a string as described [here](https://docs.zitadel.com/docs/apis/openidoauth/authn-methods#client-secret-basic). +You need to create a string as described [here](../../../apis/openidoauth/authn-methods#client-secret-basic). Use a programming language of your choice or manually create the strings with online tools (don't use these secrets for production) like: @@ -107,7 +107,7 @@ Export the result to the environment variable `BASIC_AUTH`. ### Create Auth Request -You need to create a valid auth request, including the reserved scope `urn:zitadel:iam:user:metadata`. Please refer to our API documentation for more information about [reserved scopes](https://docs.zitadel.com/docs/apis/openidoauth/scopes#reserved-scopes). +You need to create a valid auth request, including the reserved scope `urn:zitadel:iam:user:metadata`. Please refer to our API documentation for more information about [reserved scopes](../../../apis/openidoauth/scopes#reserved-scopes). diff --git a/docs/docs/guides/solution-scenarios/b2c.mdx b/docs/docs/guides/solution-scenarios/b2c.mdx index 65922d3fb9..b14ad60b66 100644 --- a/docs/docs/guides/solution-scenarios/b2c.mdx +++ b/docs/docs/guides/solution-scenarios/b2c.mdx @@ -103,6 +103,6 @@ Read more about Authorization in our [Guide](../integrate/oauth-recommended-flow ## Learn more -- [Creating an organization](../manage/console/organizations#exercise---create-a-new-organization) +- [Creating an organization](../manage/console/organizations#create-a-new-organization) - [Organization Branding](../manage/customize/branding) - [Authorization](../integrate/oauth-recommended-flows) diff --git a/docs/docs/legal/introduction.mdx b/docs/docs/legal/introduction.mdx index 3af448d1b1..ef92840c0c 100644 --- a/docs/docs/legal/introduction.mdx +++ b/docs/docs/legal/introduction.mdx @@ -20,7 +20,6 @@ All documents will be provided in English language. - diff --git a/docs/docs/manuals/user-register.md b/docs/docs/manuals/user-register.md index 1bec6d3916..a29d8de64a 100644 --- a/docs/docs/manuals/user-register.md +++ b/docs/docs/manuals/user-register.md @@ -4,23 +4,23 @@ title: User Register ## Organization and user registration -Zitadel allows users to register a organization and/or user with just a few steps. +ZITADEL allows users to register a organization and/or user with just a few steps. A. Register an organization 1. Create an organization 2. Verify your email - 3. Login to Zitadel and manage the organization + 3. Login to ZITADEL and manage the organization B. Create User 1. An administrator can create and manage users within console. -C. Enable selfregistration for User +C. Enable Self Registration for User 1. Create an organization as above 2. Create custom policy 3. Enable the "Register allowed" flag in the Login Policy - 4. Connect your application and add the applications [scope](https://docs.zitadel.com/architecture/#Custom_Scopes) to the redirect URL. + 4. Connect your application and add the applications [scope](../apis/openidoauth/scopes) to the redirect URL. This will enable the register option in the login dialog and will register the user within your organization if he does not already have an account. @@ -32,16 +32,13 @@ Create User ![Create User](/img/create-user.gif) -Enable Selfregister +Enable Self Register ![Enable Selfregister](/img/enable-selfregister.gif) - - ## Self Register -When self registration is enabled, users can register themselfes in the organanization without any administrative effort. +When self registration is enabled, users can register themselves in the organization without any administrative effort. Self Register ![Self Register](/img/self-register.gif) -