initial commit

Author: asaf

.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

README.md

@@ -0,0 +1,33 @@
+# Website
+
+This website is built using [Docusaurus 2](https://v2.docusaurus.io/), a modern static website generator.
+
+## Installation
+
+```console
+yarn install
+```
+
+## Local Development
+
+```console
+yarn start
+```
+
+This command starts a local development server and open up a browser window. Most changes are reflected live without having to restart the server.
+
+## Build
+
+```console
+yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+## Deployment
+
+```console
+GIT_USER=<Your GitHub username> USE_SSH=true yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

blog/2018-05-14-what-is-scim.md

@@ -0,0 +1,71 @@
+---
+slug: what-is-scim
+title: What is SCIM
+description: An introduction to the System for Cross-domain Identity Management.
+image: /img/blog/scim-card.png
+author: Asaf Shakarzy
+author_title: Core Team
+author_url: https://github.com/asaf
+tags: ["SCIM", "provisioning", "cloud"]
+---
+
+Over the last decade, the world has beeing moving to the cloud, with legacy and on-premise applications side by side.
+
+Such hybrid architecture arises many technological complexities. One of the challenges is about how to securely exchange and provision identities between the different parties.
+
+SCIM standardizes how identity resources such _Users_ and _Groups_ look like and how to exchange them between the different applications.
+
+<!-- truncate -->
+
+By simplyfing the whole identity provisioning process, it reduce total integration costs and increase security.
+
+Quote from RFC:
+
+    The SCIM specification is designed to manage user identity in
+    cloud-based applications and services in a standardized way to
+    enable interoperability, security, and scalability.
+
+## Why SCIM?
+
+Without SCIM, each application would have its own identities representation and protocol.
+
+Special connectors would be required per application to exchange identities.
+
+The lack of a standard requires a lot of effort in order to integrate and exchange identities between each two parties.
+
+It is a very costly process and may lead to mistaks and complexities which impact the overall security.
+
+## How SCIM works?
+
+SCIM is divided into two parts: [the schema](https://tools.ietf.org/html/rfc7643) that defines how resources such as _users_ and _groups_ look like and [the protocol](https://tools.ietf.org/html/rfc7644) that defines how those resources should be exchanged (_added_, _removed_, _updated_ and so on).
+
+SCIM is built for the cloud and is based on standard cloud tech such as REST API & JSON.
+
+In SCIM, there are two parties: Clients and Service Providers.
+
+A service provider (SP) is an application such as _Slack_ or _corporate app_ that requires to store identities and access. A client is the party that interacts with the SP in order to read and manage its identities automatically. a good example of a client is CrossID as it can interact with SCIM applications seamlessly.
+
+## CrossID and SCIM
+
+CrossID can intreact with any SCIM application with very minimal integration effort.
+
+When changes are made in HR to employees, CrossID can sync those changes to SCIM apps according to corporate policies.
+
+For example, if a sales manager joins the company it can create a user in CRM automatically and grant the relevant access according to the sales region.
+
+When employee leaves the company it will automatically de-provision any users and access the employee has.
+
+CrossID can also read all identities and privileges from SCIM apps and save those details in its own store.
+This is handful in order to consolidate identities, detect vulnerabilities and exccessive access and notify or take actions when such incidents occur.
+
+It even takes SCIM further by exposing SCIM protocol to the outside world and act as an intermediate between other IDPs and corproate applications.
+
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
+<img alt="CrossID-SCIM" src={useBaseUrl('img/blog/crossid-scim.png')} />
+
+## Conclusions
+
+SCIM make it easier, faster and cheaper to exchange identities across applications.
+
+When used in conjunction with SSO standards such as Oauth2/OIDC or SAML, SCIM provides IT an end-to-end standard solution for identity and access management.

blog/2018-08-19-scim-schema-ext.md

@@ -0,0 +1,79 @@
+---
+slug: scim-schema-extensions
+title: SCIM Schema Extensions
+description: What are SCIM schema extensions and how to use them.
+author: Asaf Shakarzy
+author_title: Core Team
+author_url: https://github.com/asaf
+tags: ["SCIM", "provisioning", "cloud"]
+---
+
+## Preface
+
+SCIM Schema is a logical group of attributes,
+
+Every resource type (such "User" or "Group") has a primary schema and possibly optional extensions.
+
+The main schema defines how resources (e.g., "users") of some resource type (e.g., "User") look like,
+
+<!-- truncate -->
+
+For example the _urn:ietf:params:scim:schemas:core:2.0:User_ schema defines how a User should look like,
+
+It is encouraged to use this core schema by every application that supports users,
+
+But what happens when we need other attributes that are not covered by the primary schema? for instance, lets say we want to store the user's manager details,
+since the manager is another user within the system, we want to store a reference to it, manager doesn't exist in the core User schema, thus we need an extension
+that provides the definition of this attribute,
+
+Luckily, SCIM comes with another schema named [enterprise](https://tools.ietf.org/html/rfc7643#section-4.3), which is an extension to the core user schema and can be used whenever organization attributes are needed,
+
+## JSON representation of User with extension
+
+SCIM distinguishes between the attributes of the primary schema and the extensions by placing the primary schema attributes in the root of the document while extension attributes are stored under the namespace of the extension.
+
+Here is a JSON of a user with the enterprise extension:
+
+```json
+{
+  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
+  "id": "2819c223-7f76-453a-919d-413861904646",
+  "externalId": "701984",
+  "userName": "[email protected]",
+  "name": {
+    "formatted": "Ms. Barbara J Jensen, III",
+    "familyName": "Jensen",
+    "givenName": "Barbara"
+  }
+  "displayName": "Babs Jensen",
+  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
+    "employeeNumber": "701984",
+    "costCenter": "4130",
+    "organization": "Universal Studios",
+    "division": "Theme Park",
+    "department": "Tour Operations",
+    "manager": {
+      "value": "26118915-6090-4610-87e4-49d8ca9f808d",
+      "$ref": "../Users/26118915-6090-4610-87e4-49d8ca9f808d",
+      "displayName": "John Smith"
+    }
+  },
+  "meta": {
+    "resourceType": "User",
+  }
+}
+```
+
+Lets explain the important attributes here:
+
+_schemas_: Since this is a user record, it must have the _urn:ietf:params:scim:schemas:core:2.0:User_
+but this user also have some enterprise attributes (e.g., "costCenter", "manager") it also have the _urn:ietf:params:scim:schemas:extension:enterprise:2.0:User_ schema.
+
+Primary attributes (such _id_, _externalId_, etc) are defined in the root level of the record.
+
+Please note: The extension schemas are required to be mentioned only if the record has attributes of the extension,
+for example, some user records may not have the _enterprise_ schema if they don't don't store any of the enterprise attributes.
+
+_urn:ietf:params:scim:schemas:extension:enterprise:2.0:User_: Every attribute of the _enterprise_ extension must be defined under the extension urn.
+
+This way we can distinguish from attributes defined in the primary schema and attributes defined in the extensions.

blog/2021-02-06-nextjs-i18n.md

@@ -0,0 +1,133 @@
+---
+slug: nextjs-i18n
+title: nextjs I18n, zero deps
+author: Asaf Shakarzy
+author_title: Core Team
+author_url: https://github.com/asaf
+tags: [nextjs, react, jamstack]
+---
+
+NextJS already ships with [built in support for i18n](https://nextjs.org/docs/advanced-features/i18n-routing).
+
+But extra bits are required to perform the actual translation.
+
+While it's possible to use dependencies such as `react-intl`, this post shows a much simpler and cleaner approach
+that scales right, no dependencies required!
+
+<!--truncate-->
+
+## Configuring I18N locales in next.config.js
+
+First, lets add support for _english_ and _japanese_ locales, here is our `next.config.js`:
+
+```json
+module.exports = {
+  i18n: {
+    locales: ["en", "ja"],
+    defaultLocale: "en",
+  },
+};
+```
+
+next.js generates pages for default, _en_ and _ja_ URLs paths:
+
+- default to english: _http://localhost:3000_
+- english locale: _http://localhost:3000/en_
+- japanese locale: http://localhost:3000/ja
+- any other locales which are not specified in _locales_ would cause 404 (e.g.,: http://localhost:3000/he)
+
+## Where to store messages translations
+
+We could store the messages in a single file in the form of _page_._key_
+
+```js
+{
+    en: {
+        index.welcome: 'Welcome to'
+    },
+    ja: {
+        index.welcome: 'ようこそ'
+    }
+}
+```
+
+The other alternative is to store messages on each component file.
+
+I personally prefer the _per component_ approach as it scales right, no need to maintain prefixes to avoid collisions and every piece of code related to a component stays within the same file, same as where we store PropTypes.
+
+To perform the actual translation, we have to:
+
+1. `useRouter()` hook to determine the current locale.
+1. use that locale to find a message in locale's messages.
+1. do the translation, preferably support placeholders in messages.
+
+## The i18n hook
+
+Lets write a hook to make the actual translation even simpler:
+
+```js
+import { useCallback } from "react";
+import { useRouter } from "next/router";
+
+// format("hello {0}", "world") returns "hello world"
+const format = (msg, ...args) => {
+  for (let k in args) {
+    msg = msg.replace("{" + k + "}", args[k]);
+  }
+  return msg;
+};
+
+// useI18n is a react hook that returns t func, which translates a message according to current locale.
+export function useI18n(msgs) {
+  const router = useRouter();
+  const { locale } = router;
+
+  const t = useCallback(
+    (id, ...args) => {
+      const lmsgs = msgs[locale];
+      const msg = lmsgs[id] || msgs.en[id] || id;
+
+      return format(msg, ...args);
+    },
+    [locale]
+  );
+
+  return {
+    t,
+    locale,
+  };
+}
+
+export default useI18n;
+```
+
+Here's example how to use the hook:
+
+```js
+export default function Home() {
+  const { t } = useI18n(msgs);
+  return (
+    <main>
+      <h1 className={styles.title}>{t("welcome_to", "next.js")}</h1>
+    </main>
+  );
+}
+
+const msgs = {
+  en: {
+    welcome_to: "Welcome to {0}",
+  },
+  ja: {
+    welcome_to: "ようこそ {0}",
+  },
+};
+```
+
+1. We pass msgs into the _useI18n_ hook.
+1. The hook determine the current locale using `useRouter()`
+1. The hook uses the corresponding locale key within the msgs object.
+1. The hook translate the message with support for placeholders.
+
+Try to hit `http://localhost:3000/en` or `http://localhost:3000/je` to see the translation in english and japanese, respectively.
+
+Code sample available in [https://github.com/asaf/nextjs-i18n-example](https://github.com/asaf/nextjs-i18n-example)

docs/concepts/application.md

@@ -0,0 +1,22 @@
+---
+id: application
+title: Application
+sidebar_label: Application
+slug: /concepts/application
+description: What is an Application
+---
+
+An _app_ represents your application where users logs in.
+
+An app is typically a web server but today SPA and native apps are also common.
+
+### App Types
+
+| App Type                      | Client Type | Description                                                                 |
+| ----------------------------- | ----------- | --------------------------------------------------------------------------- |
+| Native                        | public      | Mobile, Desktop, Smart device and CLI (e.g., _Android_, _Apple TV_, _iOS_.) |
+| Single Page Application (SPA) | public      | Javascript front-end app with no server (e.g., _React.js_ or _Vue_)         |
+| Server-side                   | private     | Typically a web server (e.g., _Node.js_, _Golang_, _PHP_)                   |
+| Machine to Machine            | private     | Server side worker such as daemon or a micro service.                       |
+
+<!--|                           | Device      | public                                                                      | A device such as Smart TV or IoT device. | || -->