diff --git a/.gitignore b/.gitignore
index 9e0bf7ed4e..0d0a4c0866 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,3 +27,4 @@ en/asgardeo/site
# Python virtula environment
.venv
+en/asgardeo/__pycache__/
diff --git a/VERSION b/VERSION
index d00d4f6fd3..8a14e28e7e 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-0.0.230
+0.0.267
diff --git a/en/asgardeo/docs/apis/restapis/actions.yaml b/en/asgardeo/docs/apis/restapis/actions.yaml
index 0bf97f5c92..0f5bdf57c5 100644
--- a/en/asgardeo/docs/apis/restapis/actions.yaml
+++ b/en/asgardeo/docs/apis/restapis/actions.yaml
@@ -500,127 +500,6 @@ paths:
curl --location --request POST 'https://api.asgardeo.io/t/{organization-name}/api/server/v1/actions/{actionType}/{actionId}/deactivate' \
-H 'Authorization: Bearer {bearer_token}'
- /actions/{actionType}/{actionId}/{authType}:
- put:
- tags:
- - Actions Endpoint
- summary: Update Action Authentication
- description: "This API updates authentication mechanism for the endpoint configured for the action. \n\n
- Scope (Permission) required: ``internal_action_mgt_update``\n\n"
- operationId: updateActionEndpointAuthentication
- parameters:
- - name: actionType
- in: path
- description: Name of the Action Type.
- required: true
- schema:
- enum:
- - preIssueAccessToken
- - name: actionId
- in: path
- description: Unique identifier of the action.
- required: true
- schema:
- type: string
- - name: authType
- in: path
- description: Authentication Type of the Action Endpoint.
- required: true
- schema:
- enum:
- - none
- - basic
- - apiKey
- - bearer
- requestBody:
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/AuthTypeProperties'
- description: This represents the updating authentication mechanism for the endpoint configured.
- required: true
- responses:
- '200':
- description: OK
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/ActionResponse'
- '400':
- description: Bad Request
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- '401':
- description: Unauthorized
- '403':
- description: Forbidden
- '404':
- description: Not Found
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- '500':
- description: Server Error
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- '501':
- description: Not Implemented
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- x-codeSamples:
- - lang: Curl(Bearer)
- source: |
- curl --location --request PUT 'https://api.asgardeo.io/t/{organization-name}/api/server/v1/actions/{actionType}/{actionId}/bearer' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Bearer {bearer_token}' \
- -d '{
- "properties": {
- "accessToken": "token"
- }
- }'
- - lang: Curl(Basic)
- source: |
- curl --location --request PUT 'https://api.asgardeo.io/t/{organization-name}/api/server/v1/actions/{actionType}/{actionId}/basic' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Bearer {bearer_token}' \
- -d '{
- "properties": {
- "username": "username",
- "password": "password"
- }
- }'
- - lang: Curl(API Key)
- source: |
- curl --location --request PUT 'https://api.asgardeo.io/t/{organization-name}/api/server/v1/actions/{actionType}/{actionId}/apiKey' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Bearer {bearer_token}' \
- -d '{
- "properties": {
- "header": "header",
- "value": "value"
- }
- }'
- - lang: Curl(None)
- source: |
- curl --location --request PUT 'https://api.asgardeo.io/t/{organization-name}/api/server/v1/actions/{actionType}/{actionId}/none' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Bearer {bearer_token}' \
- -d '{
- "properties": {}
- }'
- x-codegen-request-body-name: body
-
components:
securitySchemes:
OAuth2:
@@ -948,13 +827,6 @@ components:
- $ref: '#/components/schemas/BearerAuthentication'
- $ref: '#/components/schemas/NoAuthentication'
- AuthTypeProperties:
- oneOf:
- - $ref: '#/components/schemas/Basic'
- - $ref: '#/components/schemas/ApiKey'
- - $ref: '#/components/schemas/Bearer'
- - $ref: '#/components/schemas/None'
-
Error:
type: object
properties:
diff --git a/en/asgardeo/docs/apis/restapis/scim2-users.yaml b/en/asgardeo/docs/apis/restapis/scim2-users.yaml
index 14950335eb..fc6dd73b4b 100644
--- a/en/asgardeo/docs/apis/restapis/scim2-users.yaml
+++ b/en/asgardeo/docs/apis/restapis/scim2-users.yaml
@@ -676,16 +676,39 @@ components:
$ref: '#/components/schemas/UserResponseObject'
UserSearchRequestObject:
type: object
- example:
+ properties:
schemas:
- - urn:ietf:params:scim:api:messages:2.0:SearchRequest
+ type: object
+ items:
+ type: string
+ example:
+ - urn:ietf:params:scim:api:messages:2.0:SearchRequest
attributes:
- - name.familyName
- - userName
- filter: userName sw ki and name.familyName co err
- domain: DEFAULT
- startIndex: 1
- count: 10
+ type: array
+ description: SCIM defined attributes parameter.
+ items:
+ type: string
+ example:
+ - name.familyName
+ - userName
+ filter:
+ type: string
+ description: The expression used for filtering. Supported filters are ew, eq, co, sw, and and.
+ example: userName sw ki and name.familyName co err
+ domain:
+ type: string
+ description: The name of the user store where filtering needs to be applied.
+ example: DEFAULT
+ startIndex:
+ type: integer
+ format: int32
+ description: The 1-based index of the first query result
+ example: 1
+ count:
+ type: integer
+ format: int32
+ description: Specifies the desired maximum number of query results per page. (For organizations created on or after November 19, 2024, a threshold value of 100 will be applied to the count parameter. To fetch more users, use pagination.)
+ example: 10
UserUpdateObject:
type: object
properties:
@@ -825,4 +848,4 @@ components:
detail:
type: string
example: 'No user with the id : 008bba85-451d-414b-87de-c03b5a1f4217 in
- the user store.'
+ the user store.'
\ No newline at end of file
diff --git a/en/asgardeo/docs/apis/restapis/user-store.yaml b/en/asgardeo/docs/apis/restapis/user-store.yaml
index 673e2673a3..0e7a50679d 100644
--- a/en/asgardeo/docs/apis/restapis/user-store.yaml
+++ b/en/asgardeo/docs/apis/restapis/user-store.yaml
@@ -351,7 +351,7 @@ paths:
-d '[
{
"operation": "REPLACE",
- "path": "/properties/disabled",
+ "path": "/properties/Disabled",
"value": "true"
}
]'
@@ -871,7 +871,7 @@ components:
path:
type: string
description: A JSON-Pointer
- example: /properties/disabled
+ example: /properties/Disabled
value:
type: string
description: The value to be used within the operations
diff --git a/en/asgardeo/docs/assets/img/guides/authorization/access-token/access-token-attributes.png b/en/asgardeo/docs/assets/img/guides/authorization/access-token/access-token-attributes.png
new file mode 100644
index 0000000000..b5932d8df3
Binary files /dev/null and b/en/asgardeo/docs/assets/img/guides/authorization/access-token/access-token-attributes.png differ
diff --git a/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png b/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png
index 30ca6839ff..8f4e5666fb 100644
Binary files a/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png and b/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png differ
diff --git a/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png b/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png
deleted file mode 100644
index 302608d455..0000000000
Binary files a/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png and /dev/null differ
diff --git a/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-general.png b/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-general.png
index d71135309f..635ffe3dd3 100644
Binary files a/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-general.png and b/en/asgardeo/docs/assets/img/guides/organization/attributes/edit-attributes-general.png differ
diff --git a/en/asgardeo/docs/assets/img/guides/organization/attributes/enable-for-user-store.png b/en/asgardeo/docs/assets/img/guides/organization/attributes/enable-for-user-store.png
new file mode 100644
index 0000000000..13cdd26cfc
Binary files /dev/null and b/en/asgardeo/docs/assets/img/guides/organization/attributes/enable-for-user-store.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/accessing-protected-api.md b/en/asgardeo/docs/complete-guides/nodejs/accessing-protected-api.md
new file mode 100644
index 0000000000..aea2a37ef7
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/accessing-protected-api.md
@@ -0,0 +1,138 @@
+---
+template: templates/complete-guide.html
+heading: Accessing protected API from your Node.js app
+read_time: 2 min
+---
+
+In this section, we will focus on how to call a secure API from your Node.js app using the other token—the access token.
+
+For simplicity, let's assume that the APIs we’re calling are secured by the same Identity Provider (IdP) and use the same issuer— in this case, the same {{product_name}} organization. This is typical when Node.js apps are interacting with internal APIs within the same organization.
+
+!!! tip "Tip"
+
+ If your app needs to call APIs secured by a different IdP, you’ll need to exchange your current access token for a new one issued by the IdP securing those APIs. This can be done using the OAuth2 token exchange grant type or other supported grant types. We will cover these scenarios in a separate guide.
+
+In the following example we'll see how to call a protected API endpoint, such as [scim2/Me](https://wso2.com/asgardeo/docs/apis/scim2-me/) (to get the user profile details after signing in). In this case, the SCIM 2 endpoint is secured by the same {{product_name}} organization. {{product_name}} provides a SCIM 2 API for managing users within your organization. While user management with SCIM 2 is a topic for a different guide, we will use the API as part of our current guide.
+
+If you observe the `routes/auth.js` file, you can see that the {{product_name}} strategy loads the access token in the `accessToken` parameter of the `verify` callback. This access token can be used to call the protected API.
+
+Let's return the access token from the callback and serialize it to the session.
+
+You will notice that the {{product_name}} documentation lists the scopes required to access the SCIM 2 API. In this case, the `internal_login` scope is required to access the `/scim2/Me` endpoint.
+
+We will add the `internal_login` scope as well to the `scope` parameter in the {{product_name}} strategy configuration.
+
+```javascript hl_lines="23 38 51"
+var passport = require("passport");
+var AsgardeoStrategy = require("passport-asgardeo");
+const ASGARDEO_BASE_URL = "https://api.asgardeo.io/t/";
+
+passport.use(
+ new AsgardeoStrategy(
+ {
+ issuer:
+ ASGARDEO_BASE_URL + process.env.ASGARDEO_ORGANISATION + "/oauth2/token",
+ authorizationURL:
+ ASGARDEO_BASE_URL +
+ process.env.ASGARDEO_ORGANISATION +
+ "/oauth2/authorize",
+ tokenURL:
+ ASGARDEO_BASE_URL + process.env.ASGARDEO_ORGANISATION + "/oauth2/token",
+ userInfoURL:
+ ASGARDEO_BASE_URL +
+ process.env.ASGARDEO_ORGANISATION +
+ "/oauth2/userinfo",
+ clientID: process.env.ASGARDEO_CLIENT_ID,
+ clientSecret: process.env.ASGARDEO_CLIENT_SECRET,
+ callbackURL: "/oauth2/redirect",
+ scope: ["profile internal_login"],
+ },
+ function verify(
+ issuer,
+ uiProfile,
+ idProfile,
+ context,
+ idToken,
+ accessToken,
+ refreshToken,
+ params,
+ verified
+ ) {
+ return verified(null, {
+ uiProfile: uiProfile,
+ accessToken: accessToken,
+ });
+ }
+ )
+);
+
+passport.serializeUser(function (user, cb) {
+ process.nextTick(function () {
+ cb(null, {
+ id: user?.uiProfile?.id,
+ username: user?.uiProfile?._json?.username,
+ givenName: user?.uiProfile?.name?.givenName,
+ familyName: user?.uiProfile?.name?.familyName,
+ accessToken: user?.accessToken,
+ });
+ });
+});
+
+passport.deserializeUser(function (user, cb) {
+ process.nextTick(function () {
+ return cb(null, user);
+ });
+});
+...
+```
+
+Now we can use the access token to call the protected API. Let's modify the `routes/users.js` to try out the SCIM 2 API call.
+
+```javascript hl_lines="4 8-35"
+var express = require("express");
+var ensureLogIn = require("connect-ensure-login").ensureLoggedIn;
+var router = express.Router();
+const ASGARDEO_BASE_URL = "https://api.asgardeo.io/t/";
+
+var ensureLoggedIn = ensureLogIn();
+/* GET users listing. */
+router.get("/", ensureLoggedIn, async function (req, res, next) {
+ try {
+ console.log("Calling scim2/Me endpoint");
+ const response = await fetch(
+ ASGARDEO_BASE_URL + process.env.ASGARDEO_ORGANISATION + "/scim2/Me",
+ {
+ method: "GET",
+ headers: {
+ Accept: "application/scim+json",
+ "Content-Type": "application/scim+json",
+ Authorization: `Bearer ${req?.user?.accessToken}`,
+ },
+ }
+ );
+
+ if (!response.ok) {
+ throw new Error(
+ "Response: " + JSON.stringify(await response.json(), null, 2)
+ );
+ }
+
+ console.log(
+ "Protected data fetched. Response: " +
+ JSON.stringify(await response.json(), null, 2)
+ );
+ } catch (error) {
+ console.error("Failed to fetch protected data: ", error);
+ }
+
+ res.send("This is a protected resource");
+});
+
+module.exports = router;
+```
+
+When you login to the application and navigate to the `/users` route, you will see that the SCIM 2 API is called and the protected data is fetched successfully. The response will be logged in the terminal.
+
+![Accessing protected API]({{base_path}}/complete-guides/nodejs/assets/img/image16.png){: width="800" style="display: block; margin: 0;"}
+
+In this step, we have successfully called a protected API from our Node.js app using the access token. This is a common requirement in many applications. Next you can look into additional features that {{product_name}} offers to make the authentication flow more diverse and secure.
\ No newline at end of file
diff --git a/en/asgardeo/docs/complete-guides/nodejs/add-login-and-logout.md b/en/asgardeo/docs/complete-guides/nodejs/add-login-and-logout.md
new file mode 100644
index 0000000000..58052a23f0
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/add-login-and-logout.md
@@ -0,0 +1,305 @@
+---
+template: templates/complete-guide.html
+heading: Add login and logout to your app
+read_time: 2 min
+---
+
+## Modify Index page
+
+Let's create a simple login page for our app.
+
+```bash
+touch views/login.ejs
+```
+
+Open `views/login.ejs` and add the following code:
+
+```html
+
+
+
+
+
+ <%= title %>
+
+
+
+
+
+
+
+
+
+
+
+```
+
+Next, we will modify the `routes/index.js` file to show the login page when the user is not authenticated.
+
+```javascript hl_lines="6-10"
+var express = require("express");
+var router = express.Router();
+
+/* GET home page. */
+router.get("/", function (req, res, next) {
+ if (req.isAuthenticated()) {
+ res.render("index", { title: "Express" });
+ } else {
+ res.render("login", { title: "Express" });
+ }
+});
+
+module.exports = router;
+```
+
+## Add routes
+
+When the user clicks the "Login with Asgardeo" button, they will be redirected to our app's login page, which is hosted by {{product_name}}. Once on that page, the user will log in by providing their credentials. After they've logged in, the user will be redirected back to our app.
+
+Open `routes/auth.js` and add the following code at the end of the file, which creates two routes. The first will redirect the user to the sigin page. The second will process the authentication result when the user is redirected back.
+
+```javascript
+var express = require("express");
+var qs = require("querystring");
+var router = express.Router();
+
+router.get("/login", passport.authenticate("asgardeo"));
+
+router.get(
+ "/oauth2/redirect",
+ passport.authenticate("asgardeo", {
+ successRedirect: "/",
+ failureRedirect: "/login",
+ })
+);
+
+module.exports = router;
+```
+Next, we need to add these routes to our app. Open `app.js` and modify the file as shown below to require the new auth router and add it to the app.
+
+```javascript hl_lines="11 27"
+require("dotenv").config();
+
+var createError = require('http-errors');
+var express = require('express');
+var path = require('path');
+var cookieParser = require('cookie-parser');
+var logger = require('morgan');
+
+var indexRouter = require('./routes/index');
+var usersRouter = require('./routes/users');
+var authRouter = require("./routes/auth");
+
+var app = express();
+
+// view engine setup
+app.set('views', path.join(__dirname, 'views'));
+app.set('view engine', 'ejs');
+
+app.use(logger('dev'));
+app.use(express.json());
+app.use(express.urlencoded({ extended: false }));
+app.use(cookieParser());
+app.use(express.static(path.join(__dirname, 'public')));
+
+app.use('/', indexRouter);
+app.use('/users', usersRouter);
+app.use("/", authRouter);
+
+// catch 404 and forward to error handler
+app.use(function(req, res, next) {
+ next(createError(404));
+});
+
+// error handler
+app.use(function(err, req, res, next) {
+ // set locals, only providing error in development
+ res.locals.message = err.message;
+ res.locals.error = req.app.get('env') === 'development' ? err : {};
+
+ // render the error page
+ res.status(err.status || 500);
+ res.render('error');
+});
+
+module.exports = app;
+```
+
+The routes have been added to the app. Next we need to maintain state when redirecting to {{product_name}}.
+
+## Maintaining the session
+
+When a user signs in to our app via our app's {{product_name}}-hosted sign in page, they are redirected to {{product_name}}. {{product_name}} takes care of authenticating the user and then redirects them back to our app.
+
+For security, state needs to be maintained between these two redirects. Passport does this automatically, but the app first needs session support. Let's add that now.
+
+Begin by installing the necessary dependencies:
+
+```bash
+npm install express-session
+npm install connect-sqlite3
+```
+
+Open `app.js` and modify the file as shown below to add passport authentication with session support.
+
+```javascript hl_lines="8-10 27-35"
+require("dotenv").config();
+
+var createError = require('http-errors');
+var express = require('express');
+var path = require('path');
+var cookieParser = require('cookie-parser');
+var logger = require('morgan');
+var session = require("express-session");
+var passport = require("passport");
+var SQLiteStore = require("connect-sqlite3")(session);
+
+var indexRouter = require('./routes/index');
+var usersRouter = require('./routes/users');
+var authRouter = require("./routes/auth");
+
+var app = express();
+
+// view engine setup
+app.set('views', path.join(__dirname, 'views'));
+app.set('view engine', 'ejs');
+
+app.use(logger('dev'));
+app.use(express.json());
+app.use(express.urlencoded({ extended: false }));
+app.use(cookieParser());
+app.use(express.static(path.join(__dirname, 'public')));
+app.use(
+ session({
+ secret: "keyboard cat",
+ resave: false,
+ saveUninitialized: false,
+ store: new SQLiteStore({ db: "sessions.db", dir: "./var/db" }),
+ })
+);
+app.use(passport.authenticate("session"));
+
+app.use('/', indexRouter);
+app.use('/users', usersRouter);
+app.use("/", authRouter);
+
+// catch 404 and forward to error handler
+app.use(function(req, res, next) {
+ next(createError(404));
+});
+
+// error handler
+app.use(function(err, req, res, next) {
+ // set locals, only providing error in development
+ res.locals.message = err.message;
+ res.locals.error = req.app.get('env') === 'development' ? err : {};
+
+ // render the error page
+ res.status(err.status || 500);
+ res.render('error');
+});
+
+module.exports = app;
+```
+
+Run the following command to create the SQLite database location:
+
+```bash
+mkdir -p ./var/db
+```
+
+Next we need to configure Passport to manage the login session by adding serializeUser and deserializeUser functions. Open `routes/auth.js` and add the following code lines after AsgardeoStrategy configuration.
+
+```javascript
+passport.serializeUser(function (user, cb) {
+ process.nextTick(function () {
+ cb(null, {
+ id: user?.uiProfile?.id,
+ username: user?.uiProfile?._json?.username,
+ givenName: user?.uiProfile?.name?.givenName,
+ familyName: user?.uiProfile?.name?.familyName,
+ });
+ });
+});
+
+passport.deserializeUser(function (user, cb) {
+ process.nextTick(function () {
+ return cb(null, user);
+ });
+});
+```
+
+Now, let's try signing in.
+
+Start the server:
+
+```bash
+npm start
+```
+
+Open `http://localhost:3000` and click the "Login with Asgardeo" button. You will be redirected to the {{product_name}} login page. Enter the user credentials and click "Sign In". You will be redirected back to the index page.
+
+![Login page]({{base_path}}/complete-guides/nodejs/assets/img/image10.png){: width="800" style="display: block; margin: 0;"}
+
+## Log Out
+
+Now that users can sign in to the application, they'll need a way to sign out.
+
+Open `routes/auth.js` file and add the following route below the `/oauth2/redirect` route configuration:
+
+```javascript
+router.post("/logout", function (req, res, next) {
+ req.logout(function (err) {
+ if (err) {
+ return next(err);
+ }
+ var params = {
+ post_logout_redirect_uri: "http://localhost:3000/",
+ };
+ res.redirect(
+ ASGARDEO_BASE_URL +
+ process.env.ASGARDEO_ORGANISATION +
+ "/oidc/logout?" +
+ qs.stringify(params)
+ );
+ });
+});
+```
+
+We need to modify the `views/index.ejs` file as shown and add a logout button.
+
+```html hl_lines="17-21"
+
+
+
+
+
+ <%= title %>
+
+
+
+
+
+
+ <%= title %>
+
+
Welcome to <%= title %>
+
+
+
+
+
+
+
+```
+
+![Logout page]({{base_path}}/complete-guides/nodejs/assets/img/image11.png){: width="800" style="display: block; margin: 0;"}
+
+Return to the app, where you should already be signed in, and click "Log out."
+
+We've now got a working app where users can sign in and sign out!
+
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image10.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image10.png
new file mode 100644
index 0000000000..0ff46c471f
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image10.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image11.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image11.png
new file mode 100644
index 0000000000..7a21086e17
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image11.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image12.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image12.png
new file mode 100644
index 0000000000..23258331ff
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image12.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image13.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image13.png
new file mode 100644
index 0000000000..2bc6592a6b
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image13.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image14.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image14.png
new file mode 100644
index 0000000000..51509869b8
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image14.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image15.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image15.png
new file mode 100644
index 0000000000..044d19311a
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image15.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image16.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image16.png
new file mode 100644
index 0000000000..1ca5377bfc
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image16.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image5.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image5.png
new file mode 100644
index 0000000000..a483587be7
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image5.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image6.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image6.png
new file mode 100644
index 0000000000..28dde8f147
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image6.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image8.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image8.png
new file mode 100644
index 0000000000..1a908dc75d
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image8.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/assets/img/image9.png b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image9.png
new file mode 100644
index 0000000000..381de19142
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/nodejs/assets/img/image9.png differ
diff --git a/en/asgardeo/docs/complete-guides/nodejs/create-a-nodejs-app.md b/en/asgardeo/docs/complete-guides/nodejs/create-a-nodejs-app.md
new file mode 100644
index 0000000000..7fb82cade9
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/create-a-nodejs-app.md
@@ -0,0 +1,34 @@
+---
+template: templates/complete-guide.html
+heading: Create a Node.js app
+read_time: 2 min
+---
+
+For this guide, you will be creating a simple Node.js app using the npx [express-generator](https://www.npmjs.com/package/express-generator) command.
+
+Open a terminal and run the following command to create a new Node.js app using the Express.js framework (Provide a suitable name for the app):
+
+```bash
+npx express-generator passport-asgardeo-sample --view=ejs
+```
+
+Next, change the directory to the newly created app and install the dependencies.
+
+```bash
+cd passport-asgardeo-sample
+npm install
+```
+
+Then run the following command to start the application.
+
+```bash
+npm start
+```
+
+Confirm that the application is up and running by verifying the output in the terminal. Then, navigate to [http://localhost:3000](http://localhost:3000){:target="_blank"} and you should see the sample app working in the browser.
+
+This allows you to see real-time updates and debug the app as you make changes.
+
+![Navigate to localhost]({{base_path}}/complete-guides/nodejs/assets/img/image6.png){: width="800" style="display: block; margin: 0;"}
+
+At this point, you have a simple Node.js app up and running. In the next step, let’s try to integrate passport-asgardeo with the app.
diff --git a/en/asgardeo/docs/complete-guides/nodejs/display-logged-in-user-details.md b/en/asgardeo/docs/complete-guides/nodejs/display-logged-in-user-details.md
new file mode 100644
index 0000000000..47477457a4
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/display-logged-in-user-details.md
@@ -0,0 +1,117 @@
+---
+template: templates/complete-guide.html
+heading: Display logged-in user details
+read_time: 2 min
+---
+
+At this point, we’ve successfully implemented login and logout capabilities using the Passport {{product_name}} strategy. The next step is to explore how to access and display logged-in user details within the app.
+
+If you observe the `routes/auth.js` file, you can see that the {{product_name}} strategy loads the basic user attribute details in the id token, and these attributes are accessible through the `uiProfile` object in the `verify` callback.
+
+```javascript
+function verify(
+ issuer,
+ uiProfile,
+ idProfile,
+ context,
+ idToken,
+ accessToken,
+ refreshToken,
+ params,
+ verified
+) {
+ return verified(null, {
+ uiProfile: uiProfile,
+ });
+}
+```
+
+In the `serializeUser` method, we are serializing the user information to the session. This information can be accessed from the `req.user` object in the routes.
+
+```javascript
+passport.serializeUser(function (user, cb) {
+ process.nextTick(function () {
+ cb(null, {
+ id: user?.uiProfile?.id,
+ username: user?.uiProfile?._json?.username,
+ givenName: user?.uiProfile?.name?.givenName,
+ familyName: user?.uiProfile?.name?.familyName,
+ });
+ });
+});
+```
+
+To return the user object to the index view, let's modify the `routes/index.js` file as shown below.
+
+```javascript hl_lines="7"
+var express = require("express");
+var router = express.Router();
+
+/* GET home page. */
+router.get("/", function (req, res, next) {
+ if (req.isAuthenticated()) {
+ res.render("index", { title: "Express", user: req.user });
+ } else {
+ res.render("login", { title: "Express" });
+ }
+});
+
+module.exports = router;
+```
+
+Now, let's modify the `views/index.ejs` file to display the user details.
+
+```html hl_lines="12-28"
+
+
+
+
+
+ <%= title %>
+
+
+
+
+
+
+ User Profile
+
+
+
+ Username:
+ <%= user.username%>
+
+
+ First Name:
+ <%= user.givenName%>
+
+
+ Last Name:
+ <%= user.familyName%>
+
+
+
+
+
+
+
+
+```
+
+Now, when you log in to the application, you will see that the user's first name and last name are not displayed even though the username is displayed. This is because the {{product_name}} strategy does not return the first name and last name in the id token by default.
+
+![Display user details]({{base_path}}/complete-guides/nodejs/assets/img/image12.png){: width="800" style="display: block; margin: 0;"}
+
+To get the first name and last name, we need to configure the {{product_name}} application to include these attributes in the id token when we request the profile scope.
+
+Let's login to the {{product_name}} console and go to the application settings of the application you created. Then go to the User Attributes tab and update the application after checking the **First Name (given_name)** and **Last Name (family_name)** under the **Profile** scope. This will tell {{product_name}} to send the checked attributes under the profile OIDC scope.
+
+![Configure user attributes]({{base_path}}/complete-guides/nodejs/assets/img/image13.png){: width="800" style="display: block; margin: 0;"}
+
+Now, when you log in to the application again, you will see that the first name and last name are displayed along with the username.
+
+![Display user details]({{base_path}}/complete-guides/nodejs/assets/img/image14.png){: width="800" style="display: block; margin: 0;"}
+
+In the next section, we will explore how to secure routes in the application using {{product_name}} authentication.
diff --git a/en/asgardeo/docs/complete-guides/nodejs/install-passport-asgardeo.md b/en/asgardeo/docs/complete-guides/nodejs/install-passport-asgardeo.md
new file mode 100644
index 0000000000..5eac5c4d32
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/install-passport-asgardeo.md
@@ -0,0 +1,99 @@
+---
+template: templates/complete-guide.html
+heading: Install and configure Passport Asgardeo
+read_time: 2 min
+---
+
+## Install Passport and Passport Asgardeo
+
+For this integration, we are going to use Passport and the passport-asgardeo strategy. Install the dependencies using the following commands:
+
+```bash
+npm install passport
+npm install passport-asgardeo
+npm install dotenv
+```
+
+!!! Info
+
+ [Passport](https://www.passportjs.org) is an authentication middleware for Node.js that is widely used in the Node.js community. It provides a simple way to authenticate requests and manage sessions. Passport strategies are used to authenticate requests. Passport {{product_name}} strategy is a Passport strategy that allows you to authenticate with OIDC using {{product_name}}.
+
+## Configure AsgardeoStrategy
+
+Next, let's create a file that will contain authentication related functionality:
+
+```bash
+touch routes/auth.js
+```
+
+Add the following code to the `routes/auth.js` file:
+
+```javascript
+var passport = require("passport");
+var AsgardeoStrategy = require("passport-asgardeo");
+const ASGARDEO_BASE_URL = "https://api.asgardeo.io/t/";
+
+passport.use(
+ new AsgardeoStrategy(
+ {
+ issuer:
+ ASGARDEO_BASE_URL + process.env.ASGARDEO_ORGANISATION + "/oauth2/token",
+ authorizationURL:
+ ASGARDEO_BASE_URL +
+ process.env.ASGARDEO_ORGANISATION +
+ "/oauth2/authorize",
+ tokenURL:
+ ASGARDEO_BASE_URL + process.env.ASGARDEO_ORGANISATION + "/oauth2/token",
+ userInfoURL:
+ ASGARDEO_BASE_URL +
+ process.env.ASGARDEO_ORGANISATION +
+ "/oauth2/userinfo",
+ clientID: process.env.ASGARDEO_CLIENT_ID,
+ clientSecret: process.env.ASGARDEO_CLIENT_SECRET,
+ callbackURL: "/oauth2/redirect",
+ scope: ["profile"],
+ },
+ function verify(
+ issuer,
+ uiProfile,
+ idProfile,
+ context,
+ idToken,
+ accessToken,
+ refreshToken,
+ params,
+ verified
+ ) {
+ return verified(null, {
+ uiProfile: uiProfile,
+ });
+ }
+ )
+);
+```
+
+Next, let's create a `.env` file to store the domain, client ID, and client secret from the {{product_name}} Application as environment variables:
+
+```bash
+touch .env
+```
+
+Add the following environment variables to the `.env` file:
+
+```bash
+ASGARDEO_ORGANISATION=
+ASGARDEO_CLIENT_ID=
+ASGARDEO_CLIENT_SECRET=
+```
+
+Add the following line to the start of the `app.js` file to load the environment variables:
+
+```javascript hl_lines="1"
+require("dotenv").config();
+
+var createError = require("http-errors");
+var express = require("express");
+...
+```
+
+Now that the strategy is configured, we are ready to add login routes to the app.
\ No newline at end of file
diff --git a/en/asgardeo/docs/complete-guides/nodejs/introduction.md b/en/asgardeo/docs/complete-guides/nodejs/introduction.md
new file mode 100644
index 0000000000..5c6afc03d0
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/introduction.md
@@ -0,0 +1,36 @@
+---
+template: templates/complete-guide.html
+heading: Introduction
+read_time: 2 mins
+---
+
+Node.js is a popular JavaScript runtime environment that allows developers to build scalable and high-performance applications. It is widely used for building server-side applications, command-line tools, and desktop applications. Node.js is built on the V8 JavaScript engine, which is the same engine that powers Google Chrome. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.
+
+In this guide, we will be using Express.js, which is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications. It is designed for building single-page, multi-page, and hybrid web applications. Express.js is widely used for building APIs and web applications.
+
+Implementing login functionality in your Node.js app is essential for managing user access, personalizing user experiences, and securing the app. It enhances user experience, protects user data, boosts engagement, and helps ensure regulatory compliance.
+
+## Learning objectives
+
+This guide will walk you through everything you need to know about securing Node.js apps, including implementing user login in your Node.js app, integrating it with an Identity Provider (IdP) to make the login process simple and secure, and general guidelines to protect your end users. It also covers how to make secure API calls to an OAuth2-protected API within your Node.js app.
+
+In this guide, you will:
+
+* Register an application in {{product_name}}
+* Create a Node.js app from the template
+* Install passport.js and other dependencies
+* Add login and logout to your app
+* Display logged in user detail
+* Securing routes within the app
+* Accessing protected API from your Node.js app
+* Managing tokens in your Node.js app
+
+
+!!! tip "Tip"
+
+ This guide takes approximately 60 minutes to complete and covers everything required to add user login and secure your Node.js apps.
+
+
+!!! tip "Tip"
+
+ If you are already familiar with the concepts discussed in the guide, you can clone the sample Node.js application configured with {{product_name}} from the [repository](https://github.com/pabasara-mahindapala/passport-asgardeo-sample). All you need to do is registering a **Traditional Web Application** in {{product_name}} and updating the environment variables in the `.env` file as explained in the **README.md** file.
\ No newline at end of file
diff --git a/en/asgardeo/docs/complete-guides/nodejs/next-steps.md b/en/asgardeo/docs/complete-guides/nodejs/next-steps.md
new file mode 100644
index 0000000000..fabef2c104
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/next-steps.md
@@ -0,0 +1,13 @@
+---
+template: templates/complete-guide.html
+heading: Next Steps
+read_time: 1 min
+---
+This guide you just have completed, covered the adding user login for Node.js apps by integrating with an Identity Provider (IdP) and additional use cases such making calls to an OAuth2-protected API.
+
+Now that your Node.js application is secured with authentication features integrated, It is time to explore the additional features {{product_name}} offers to make the login flow more diverse and secure.
+
+- [Multi factor authentication](https://wso2.com/asgardeo/docs/guides/authentication/mfa/){:target="_blank"}
+- [Passwordless authentication](https://wso2.com/asgardeo/docs/guides/authentication/passwordless-login/){:target="_blank"}
+- [Self registration](https://wso2.com/asgardeo/docs/guides/user-accounts/configure-self-registration/){:target="_blank"}
+- [Login UI customization](https://wso2.com/asgardeo/docs/guides/branding/){:target="_blank"}
diff --git a/en/asgardeo/docs/complete-guides/nodejs/prerequisite.md b/en/asgardeo/docs/complete-guides/nodejs/prerequisite.md
new file mode 100644
index 0000000000..c044a30ef4
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/prerequisite.md
@@ -0,0 +1,13 @@
+---
+template: templates/complete-guide.html
+heading: Prerequisite
+read_time: 30 secs
+---
+
+## Before you start, ensure you have the following:
+
+* About 60 minutes
+* {{product_name}} account
+* [Node.js](https://nodejs.org/en/download/package-manager){:target="_blank"} v18+ and npm
+* A favorite text editor or IDE
+
diff --git a/en/asgardeo/docs/complete-guides/nodejs/register-an-application.md b/en/asgardeo/docs/complete-guides/nodejs/register-an-application.md
new file mode 100644
index 0000000000..51ccc59b59
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/register-an-application.md
@@ -0,0 +1,37 @@
+---
+template: templates/complete-guide.html
+heading: Register an application in Asgardeo
+read_time: 2 min
+---
+
+First unless you already have done that, you need to create an organization in {{product_name}} and register your application as a Traditional Web Application.
+
+* Sign up for a [free {{product_name}} account](https://wso2.com/asgardeo/docs/get-started/create-asgardeo-account/){:target="_blank"}
+* Sign into {{product_name}} console and navigate to **Applications > New Application.**
+* Select Traditional Web Application
+
+![Select Traditional Web Application]({{base_path}}/complete-guides/nodejs/assets/img/image5.png){: width="800" style="display: block; margin: 0;"}
+
+Next, complete the wizard popup by providing a suitable name and an authorized redirect URL. Keep OpenID Connect selected as the protocol.
+
+!!! Example
+ **name:** is-nodejs
+
+ **Authorized redirect URL:** http://localhost:3000/oauth2/redirect
+
+![Register a new application]({{base_path}}/complete-guides/nodejs/assets/img/image8.png){: width="800" style="display: block; margin: 0;"}
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use [http://localhost:3000/oauth2/redirect](http://localhost:3000/oauth2/redirect){:target="_blank"}, as the sample app will be accessible at this URL.
+
+You will need the following information available in the Quick Start tab of your app.
+
+* Client ID
+* Client Secret
+
+![Quick start guide]({{base_path}}/complete-guides/nodejs/assets/img/image9.png){: width="800" style="display: block; margin: 0;"}
+
+After creating the application, navigate to **User Management > Users** and [create a new user](https://wso2.com/asgardeo/docs/guides/users/manage-users/#onboard-users). We will use this user to log in to the Node.js app.
+
+In this step, we have registered our Node.js app as an application in the {{product_name}} console and generated the required metadata. Next, we will create a Node.js app using the Express.js framework.
diff --git a/en/asgardeo/docs/complete-guides/nodejs/securing-routes-within-the-app.md b/en/asgardeo/docs/complete-guides/nodejs/securing-routes-within-the-app.md
new file mode 100644
index 0000000000..5385fdb069
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/nodejs/securing-routes-within-the-app.md
@@ -0,0 +1,41 @@
+---
+template: templates/complete-guide.html
+heading: Securing Routes within the app
+read_time: 2 min
+---
+
+In our app, routes define the paths within the application that users can navigate to, linking URLs to specific components. Securing routes is essential to protect sensitive data, prevent unauthorized access, and ensure that only authenticated users can access certain parts of the application. In this section, let’s look at how we can secure routes using {{product_name}} authentication.
+
+You may have noticed that we have a /users route created by default from the Express generator (`users.js` file). Let’s log out from the application and try to access this route at [http://localhost:3000/users](http://localhost:3000/users). You will see that the route is accessible even when you are not logged in.
+
+Let's assume that this route contains protected information that should only be accessible to authenticated users. To secure this route, we need to add a middleware function that checks if the user is authenticated before allowing access to the route.
+
+To achieve this requirement easily, we can use the [connect-ensure-login](https://www.npmjs.com/package/connect-ensure-login) npm package. This package provides middleware that ensures a user is logged in before allowing access to a route and it integrates with Passport.js seamlessly.
+
+First, install the package by running the following command:
+
+```bash
+npm install connect-ensure-login
+```
+
+Next, import the package in the `routes/users.js` file and modify the file as shown below:
+
+```javascript hl_lines="2 5 7 8"
+var express = require("express");
+var ensureLogIn = require("connect-ensure-login").ensureLoggedIn;
+var router = express.Router();
+
+var ensureLoggedIn = ensureLogIn();
+/* GET users listing. */
+router.get("/", ensureLoggedIn, function (req, res, next) {
+ res.send("This is a protected resource");
+});
+
+module.exports = router;
+```
+
+Now when you try to access the `/users` route without logging in, you will be redirected to the login page. After logging in, you will be able to access the protected route at [http://localhost:3000/users](http://localhost:3000/users).
+
+![Securing routes]({{base_path}}/complete-guides/nodejs/assets/img/image15.png){: width="800" style="display: block; margin: 0;"}
+
+In this step, we looked into how to secure component routes within a Node.js app. Next, we will try to access a protected API from our Node.js app, which is a common requirement in many applications.
\ No newline at end of file
diff --git a/en/asgardeo/docs/complete-guides/react/accessing-protected-api.md b/en/asgardeo/docs/complete-guides/react/accessing-protected-api.md
new file mode 100644
index 0000000000..3cebf2af41
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/accessing-protected-api.md
@@ -0,0 +1,146 @@
+---
+template: templates/complete-guide.html
+heading: Accessing protected API from your React app
+read_time: 2 min
+---
+
+In this section, we will focus on how to call a secure API from your React app using the other token—the access token.
+
+For simplicity, let's assume that the APIs we’re calling are secured by the same Identity Provider (IdP) and use the same issuer— in this case, the same {{product_name}} organization. This is typical when React apps are interacting with internal APIs within the same organization.
+
+!!! tip "Tip"
+
+ If your app needs to call APIs secured by a different IdP, you’ll need to exchange your current access token for a new one issued by the IdP securing those APIs. This can be done using the OAuth2 token exchange grant type or other supported grant types. We will cover these scenarios in a separate guide.
+
+## Using SDK Built-in HTTP client
+
+You can use the `httpRequest` API provided by the Asgardeo SDK to make HTTP requests to these endpoints. This function is used to send http requests to {{product_name}} or desired backend. The developer doesn’t need to manually attach the access token since this function does it automatically.
+
+The following is a simple example of how you might use the Asgardeo SDK’s `httpRequest` to call a protected API endpoint, such as `/scim2/me` (to get the user profile details after signing in). In this case, the SCIM 2 endpoint is secured by the same {{product_name}} organization. {{product_name}} provides a SCIM 2 API for managing users within your organization. While user management with SCIM 2 is a topic for a different guide, we will use the API as part of our current guide.
+
+!!! note "Note"
+
+ The storage type must be set to `webWorker` for the token to be automatically attached. If it’s set to `sessionStorage` or `localStorage`, you may implement your own function for attaching the access token to the network request.
+
+```javascript
+
+const App = () => {
+
+
+ const { httpRequest } = useAuthContext();
+
+
+ const requestConfig = {
+ headers: {
+ "Accept": "application/json",
+ "Content-Type": "application/scim+json"
+ },
+ method: "GET",
+ url: "https://api.asgardeo.io/t//scim2/me"
+ };
+
+
+ useEffect(() => {
+ // Make a GET request to a protected endpoint
+ httpRequest(requestConfig)
+ .then((response) => {
+ // Handle successful response
+ console.log('Response:', response.data);
+ })
+ .catch((error) => {
+ // Handle error
+ console.error('Error:', error);
+ });
+ }, [])
+}
+
+```
+
+Note that you don’t need to manually specify the Authorization header under headers in `requestConfig`, as `httpRequest` function intercepts the request and attaches the access token to the network request as the Authorization header.
+
+In the above example, the final request config sent by the `httpRequest` function would be as follows
+
+```javascript
+const requestConfig = {
+ headers: {
+ "Accept": "application/json",
+ "Content-Type": "application/scim+json",
+ "Authorization": "Bearer "
+ },
+ method: "GET",
+ url: "https://api.asgardeo.io/t//scim2/me"
+ };
+
+
+```
+
+In case you want to send multiple API requests in parallel, you can use the `httpRequestAll` function to simultaneously trigger parallel network requests and receive responses after all network requests are completed.
+
+The following code snippet shows a javascript function which accepts a list of application IDs and sends multiple network requests for each app ID in parallel. The responses will contain results for each id, as an array of responses.
+
+```javascript
+import { AsgardeoSPAClient } from "@asgardeo/auth-react";
+
+
+const httpClientAll = AsgardeoSPAClient.getInstance()
+ .httpRequestAll.bind(AsgardeoSPAClient.getInstance());
+
+
+export const getApplicationsByIds = async (ids) => {
+
+
+ const requests = [];
+
+
+ for (const id of ids) {
+ requests.push({
+ headers: {
+ "Accept": "application/json",
+ "Content-Type": "application/json"
+ },
+ method: "GET",
+ url: "https://localhost:9443/applications/" + id
+ });
+ }
+
+
+ try {
+ const responses = await httpClientAll(requests);
+
+
+ return Promise.resolve(responses);
+ } catch (error) {
+ console.error(error);
+ }
+};
+
+```
+
+## Using a custom HTTP client
+
+In case you are not using the webWorker as the storage type, the `getAccessToken` function can be used to fetch the access token and manually attach it to the network request. The following is an example where the access token is fetched and manually attached to the authorization header of a Fetch request.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+
+
+const App = () => {
+ const { getAccessToken } = useAuthContext();
+
+
+ useEffect(() => {
+ getAccessToken().then(async (accessToken) => {
+ const response = await fetch("https://api.asgardeo.io/t//scim2/me", {
+ "Authorization": "Bearer " + accessToken
+ })
+ console.log(response)
+ }).catch((error) => {
+ console.log(error);
+ });
+ }, []);
+
+ .
+ .
+ .
+}
+```
diff --git a/en/asgardeo/docs/complete-guides/react/add-login-and-logout.md b/en/asgardeo/docs/complete-guides/react/add-login-and-logout.md
new file mode 100644
index 0000000000..21f9481e1a
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/add-login-and-logout.md
@@ -0,0 +1,79 @@
+---
+template: templates/complete-guide.html
+heading: Add login and logout to your app
+read_time: 2 min
+---
+
+Next, let’s implement login and logout for our React app. React hooks are a special type of functions that let you access state and other React features in React functional components. Asgardeo provides one such hook, `useAuthContext()`, to conveniently access user authentication data such as the logged in user’s information, etc and utility functions, such as a function to validate user’s authentication status, and retrieve access tokens.
+
+`useAuthContext` hook also provides us access with two key functions to perform sign in and sign out in your React application, `signIn` and `signOut` respectively. You can directly invoke the respective functions in our React application to trigger sign-in and sign-out requests as follows.
+
+Update the `App.jsx` with the following code.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+import './App.css';
+
+const App = () => {
+const { state, signIn, signOut } = useAuthContext();
+
+return (
+ <>
+ {
+ state.isAuthenticated
+ ?
+ :
+ }
+ >
+)
+};
+
+export default App;
+```
+
+Let’s look into the underlying details of what’s happening here.
+
+The `authConfig` object holds the configuration necessary for connecting the app to {{product_name}}. It includes properties like `signInRedirectURL` and `signOutRedirectURL`, which determine where users are redirected after signing in or out. The `clientID` identifies the application, and `baseUrl` specifies the Asgardeo API endpoint specific to your organization. The scope array lists the OAuth 2.0 permissions the app requires, such as `openid` and `profile`. The scops are used to indicate what user attributes are expected by our React app.
+
+The App component leverages the `useAuthContext` hook to access the authentication state (`state`) and actions (`signIn` and `signOut`). Inside the `AuthProvider`, the app conditionally renders a login or logout button based on whether the user is authenticated. If `state.isAuthenticated` is true, a "Logout" button is shown that triggers the `signOut` function. Otherwise, a "Login" button appears, which initiates the signIn process.
+
+Save the changes and re-run the application in development mode if it is not running already.
+
+```bash
+npm run dev
+```
+
+Once the application is started, you will see the homepage of the application with the changes we made.
+
+![Login screen]({{base_path}}/complete-guides/react/assets/img/image14.png){: width="800" style="display: block; margin: 0;"}
+
+Initiate Sign In
+Clicking on the login button will initiate an OIDC request. You will be able to observe the authorize request in the browser devtools as follows. To see this, right click on the application and click inspect and switch to the network tab. In the filter input, type “authorize”, and click on the sign in button.
+
+![OIDC request]({{base_path}}/complete-guides/react/assets/img/image15.png){: width="800" style="display: block; margin: 0;"}
+
+!!! tip "Tip"
+
+ The OpenID Connect specification offers several functions, known as grant types, to obtain an access token in exchange for user credentials. This example uses the authorization code grant type. In this process, the app first requests a unique code from the authentication server, which can later be used to obtain an access token. For more details on the authorization code grant type, please refer to the [Asgardeo documentation.](https://wso2.com/asgardeo/docs/guides/authentication/oidc/implement-auth-code-with-pkce/){:target="_blank"}
+
+Asgardeo will receive this authorization request and respond by redirecting the user to a login page to enter their credentials.
+
+![OIDC request]({{base_path}}/complete-guides/react/assets/img/image16.png){: width="800" style="display: block; margin: 0;"}
+
+At this stage, **you need to create a [test user in Asgardeo](https://wso2.com/asgardeo/docs/guides/users/manage-users/#onboard-users){:target="_blank"} to try out the application.** Once you create a test user, you can enter the username and password of the test user to the login screen.
+
+If the login is successful, you should be able to see the application as shown below.
+
+![Login flow]({{base_path}}/complete-guides/react/assets/img/image17.png){: width="800" style="display: block; margin: 0;"}
+
+!!! tip "Tip"
+
+ **PKCE (Proof Key for Code Exchange)** is an addition to the OAuth2 specification to make the authorization code more immune to replay attacks. It is enabled by default for public clients such as our single page React application.
+
+ If you want to disable PKCE for some reason, you can do so via following the steps below. **However, disabling PKCE for public clients such as our single page React app is highly discouraged.**
+
+ 1. Log in to the {{product_name}} console and select the application you created.
+ 2. Switch to the Protocol tab.
+ 3. Uncheck the Mandatory checkbox under PKCE section.
+
+In this section, we have added login and logout features to our React app. In the next step, we will look into how to access the user attributes of the logged in user.
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image1.png b/en/asgardeo/docs/complete-guides/react/assets/img/image1.png
new file mode 100644
index 0000000000..c4be223ec5
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image1.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image10.png b/en/asgardeo/docs/complete-guides/react/assets/img/image10.png
new file mode 100644
index 0000000000..b88ab5e4a7
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image10.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image11.png b/en/asgardeo/docs/complete-guides/react/assets/img/image11.png
new file mode 100644
index 0000000000..df87556597
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image11.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image12.png b/en/asgardeo/docs/complete-guides/react/assets/img/image12.png
new file mode 100644
index 0000000000..ab1b9c4f8f
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image12.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image13.png b/en/asgardeo/docs/complete-guides/react/assets/img/image13.png
new file mode 100644
index 0000000000..0acfd4b6fb
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image13.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image14.png b/en/asgardeo/docs/complete-guides/react/assets/img/image14.png
new file mode 100644
index 0000000000..d758aefaa3
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image14.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image15.png b/en/asgardeo/docs/complete-guides/react/assets/img/image15.png
new file mode 100644
index 0000000000..4cccdbec5c
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image15.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image16.png b/en/asgardeo/docs/complete-guides/react/assets/img/image16.png
new file mode 100644
index 0000000000..d8a814ccf7
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image16.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image17.png b/en/asgardeo/docs/complete-guides/react/assets/img/image17.png
new file mode 100644
index 0000000000..1f5f1092f8
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image17.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image18.png b/en/asgardeo/docs/complete-guides/react/assets/img/image18.png
new file mode 100644
index 0000000000..a383eabaac
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image18.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image19.png b/en/asgardeo/docs/complete-guides/react/assets/img/image19.png
new file mode 100644
index 0000000000..dc5197602d
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image19.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image2.png b/en/asgardeo/docs/complete-guides/react/assets/img/image2.png
new file mode 100644
index 0000000000..f9f9ba0fc4
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image2.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image20.png b/en/asgardeo/docs/complete-guides/react/assets/img/image20.png
new file mode 100644
index 0000000000..0972bac78b
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image20.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image3.png b/en/asgardeo/docs/complete-guides/react/assets/img/image3.png
new file mode 100644
index 0000000000..39a39a130b
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image3.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image4.png b/en/asgardeo/docs/complete-guides/react/assets/img/image4.png
new file mode 100644
index 0000000000..2b9c046ef1
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image4.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image5.png b/en/asgardeo/docs/complete-guides/react/assets/img/image5.png
new file mode 100644
index 0000000000..b5b9bdb6ca
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image5.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image6.png b/en/asgardeo/docs/complete-guides/react/assets/img/image6.png
new file mode 100644
index 0000000000..1996cbd1dc
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image6.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image7.png b/en/asgardeo/docs/complete-guides/react/assets/img/image7.png
new file mode 100644
index 0000000000..932561f25a
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image7.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image8.png b/en/asgardeo/docs/complete-guides/react/assets/img/image8.png
new file mode 100644
index 0000000000..e10051c0ad
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image8.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/assets/img/image9.png b/en/asgardeo/docs/complete-guides/react/assets/img/image9.png
new file mode 100644
index 0000000000..4ce40ad4c3
Binary files /dev/null and b/en/asgardeo/docs/complete-guides/react/assets/img/image9.png differ
diff --git a/en/asgardeo/docs/complete-guides/react/create-a-react-app.md b/en/asgardeo/docs/complete-guides/react/create-a-react-app.md
new file mode 100644
index 0000000000..465d12c07d
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/create-a-react-app.md
@@ -0,0 +1,35 @@
+---
+template: templates/complete-guide.html
+heading: Create a React app
+read_time: 2 min
+---
+
+For this guide, you will be creating a simple React app using [Vite](https://vitejs.dev/){:target="_blank"}, a modern, fast and lightweight tool that helps you quickly set up and develop modern JavaScript apps.
+
+Open a terminal, change directory to where you want to initialize the project, and run the following command to create your first React sample app.
+
+
+```bash
+npm create vite@latest asgardeo-react -- --template react
+```
+
+Running this command will create a folder with a ready-to-run boilerplate React project, with a development server to run the project and instantly reload changes to the project in your browser without manual refresh.
+
+Once the application is created, install the dependencies using the following command.
+
+```bash
+cd asgardeo-react
+npm install
+```
+
+Then run the sample in the development mode. This allows you to see real-time updates and debug the app as you make changes.
+
+```bash
+npm run dev
+```
+
+Confirm that the dev server is up and running by verifying the output in the terminal. Then, navigate to [http://localhost:5173](http://localhost:5173){:target="_blank"} and you should see the sample app working in the browser.
+
+![Navigate to localhost]({{base_path}}/complete-guides/react/assets/img/image6.png){: width="600" style="display: block; margin: 0;"}
+
+At this point, you have a simple yet fully functional React app. In the next step, let’s try to integrate an OIDC SDK with the app.
diff --git a/en/asgardeo/docs/complete-guides/react/display-logged-in-user-details.md b/en/asgardeo/docs/complete-guides/react/display-logged-in-user-details.md
new file mode 100644
index 0000000000..1b77380ea5
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/display-logged-in-user-details.md
@@ -0,0 +1,133 @@
+---
+template: templates/complete-guide.html
+heading: Display logged-in user details
+read_time: 2 min
+---
+
+At this point, we’ve successfully implemented login and logout capabilities using the Asgardeo React SDK. The next step is to explore how to access and display logged-in user details within the app. The Asgardeo React SDK loads the basic user attribute details to the authentication state, so that you can directly access those from the state (such as `state.username`) and use them in the application. First, let’s try to display the username using state.username.Replace the code in app.jsx with the following.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+import './App.css';
+
+const App = () => {
+ const { state, signIn, signOut } = useAuthContext();
+
+ return (
+ <>
+ {
+ state.isAuthenticated
+ ? <>
+
Welcome {state.username}
+
+ >
+ :
+ }
+ >
+ )
+};
+
+export default App;
+```
+
+If your React application is already running in the development mode, the home page will be reloaded and you will see the updated user interface.
+
+![Logout screen]({{base_path}}/complete-guides/react/assets/img/image18.png){: width="800" style="display: block; margin: 0;"}
+
+There may be instances where you’d need to retrieve user attributes outside React components. Asgardeo React SDK provides a [getBasicUserInfo](https://github.com/asgardeo/asgardeo-auth-react-sdk/blob/main/API.md#getbasicuserinfo){:target="_blank"} function, which allows you to retrieve the authenticated user’s basic information. The code example in the following section demonstrates this process and can be adapted to fit your application with any necessary customizations.
+
+Again, replace the code in `app.jsx` with the following.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+import { useEffect, useState } from "react";
+import './App.css';
+
+const App = () => {
+
+ const { state, getBasicUserInfo, signIn, signOut } = useAuthContext();
+ const [userInfo, setUserInfo] = useState(undefined);
+
+ useEffect(() => {
+ getBasicUserInfo().then((response) => {
+ setUserInfo(response)
+ }).catch((error) => {
+ console.error(error);
+ });
+ }, [state]);
+
+
+ return (
+ <>
+ {
+ state.isAuthenticated
+ ? <>
+
Welcome, {userInfo?.username}
+
+ >
+ :
+ }
+ >
+ )
+};
+
+export default App;
+```
+
+The above code snippet, the app utilizes the `useAuthContext` hook to access authentication state and methods such as `getBasicUserInfo`, `signIn`, and `signOut`. It also uses React's `useState` to store basic user information and `useEffect` to fetch this information whenever the authentication state changes. If the user is authenticated, the app displays a welcome message with the username and a button to log out. If the user is not authenticated, it shows a login button that triggers the sign-in process, and the errors during user info retrieval are handled by logging them to the console.
+
+Similarly, you can access the other user attributes, such as email, display name, allowed scopes, etc as well. The following code snippet shows you how you can access them in your app. Asgardeo React SDK is responsible for processing the ID token and decoding these attributes.
+
+```javascript
+
Your email: { userInfo?.email }
+
Display name: { userInfo?.displayName }
+
Allowed scopes: { userInfo?.allowedScopes }
+
Tenant domain: { userInfo?.tenantDomain }
+
Session state: { userInfo?.sessionState }
+```
+
+## Getting additional user attributes
+
+Other than the above attributes decoded and available to you by default, Asgardeo React SDK provides [getDecodedIDToken](https://github.com/asgardeo/asgardeo-auth-react-sdk/blob/main/API.md#getdecodedidtoken){:target="_blank"} method to access any other user attributes that are not exposed by `getBasicUserInfo`. This method will decode the ID token in browser storage and return the output as a JSON object.
+
+To get additional user attributes to the ID token, the application should be configured to request the specific user attributes at the time of login. For example, if you want to retrieve a user's mobile number as an attribute, you need to configure the application to request the user’s mobile number as an attribute in the ID token.
+
+1. Log in to the {{product_name}} console and select the application you created.
+2. Go to the **User Attributes** tab.
+3. Select the **phone** scope.
+4. Expand the scope, and you will see that all attributes under this scope (e.g., `mobile_number`) are selected.
+5. Click Update to save the changes.
+
+```javascript
+
+const { state, signIn, signOut, getDecodedIDToken } = useAuthContext();
+
+
+const [mobileNumber, setMobileNumber] = useState("")
+
+
+useEffect(() => {
+ if (state.isAuthenticated) {
+ getDecodedIDToken().then((decodedIdToken) => {
+ console.log(decodedIdToken);
+ setMobileNumber(decodedIdToken.phone_number)
+ }).catch((error) => {
+ console.log(error);
+ })
+ }
+}, [ state.isAuthenticated ]);
+
+
+return (
+ <>
+
Your mobile number: {mobileNumber}
+ >
+)
+
+```
+
+In the above code snippet, we run the `getDecodedIDToken` method if the user is authenticated, and print the output to the browser console. The decoded ID token response will be printed to the browser console as follows.
+
+![ID token]({{base_path}}/complete-guides/react/assets/img/image19.png){: width="800" style="display: block; margin: 0;"}
+
+In this step, we further improved our React app to display the user attributes. As the next step, we will try to secure routes within the app.
diff --git a/en/asgardeo/docs/complete-guides/react/install-asgardeo-sdk.md b/en/asgardeo/docs/complete-guides/react/install-asgardeo-sdk.md
new file mode 100644
index 0000000000..abd64ac518
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/install-asgardeo-sdk.md
@@ -0,0 +1,72 @@
+---
+template: templates/complete-guide.html
+heading: Install and configure Asgardeo SDK
+read_time: 2 min
+---
+
+## Install @asgardeo/auth-react
+
+The Asgardeo React SDK is a production-ready SDK that simplifies integrating {{product_name}} as an Identity Provider in your React applications. It provides essential features like user authentication, retrieving user information, and an HTTP client for sending network requests with attached tokens. Additionally, it ensures best practices by being Secure by Design and Secure by Default.
+
+!!! Info
+
+ Asgardeo React SDK has been developed on open standards such as OAuth2, OpenID Connect etc, therefore you can use the Asgardeo React SDK for adding authentication to your application with any other OpenID Connect identity provider such as [WSO2 Identity Server (WSO2 IS)](https://wso2.com/identity-server/){:target="_blank"} and WSO2 [Private Identity Cloud (WSO2 PIC)](https://wso2.com/private-identity-cloud/){:target="_blank"} .
+
+As the next step, run the following command to install the React SDK from the npm registry.
+
+```bash
+npm install @asgardeo/auth-react
+
+```
+
+## Add `` to your app
+
+During the previous step, we have added Asgardeo React SDK as a dependency in our app. Now we are going to use the `` component from the Asgardeo React SDK which is built on top of [React Context](https://react.dev/learn/passing-data-deeply-with-context){:target="_blank"}. The `` serves as a context provider for user login in the app. You can add the `` to your app by wrapping the root component to access authentication-related capabilities throughout the component tree.
+
+First, you need to open the project using an IDE such as VS Code. Then, as shown below, you need to wrap the **** component in `main.jsx` with the `` component. Make sure to replace the placeholders in this code from the configuration parameters that we generated in [step-3](http://localhost:8000/asgardeo/docs/complete-guides/react/register-an-application/).
+
+```javascript
+import React from 'react';
+import ReactDOM from 'react-dom/client';
+import App from './App.jsx';
+import { AuthProvider } from '@asgardeo/auth-react';
+import './index.css';
+
+const config = {
+ signInRedirectURL: "http://localhost:5173",
+ signOutRedirectURL: "http://localhost:5173",
+ clientID: "",
+ baseUrl: "https://api.asgardeo.io/t/",
+ scope: [ "openid","profile" ]
+}
+
+ReactDOM.createRoot(document.getElementById('root')).render(
+
+
+
+
+,
+);
+
+```
+
+As shown above, we used `` at the root level of the application to ensure that all components can interact with the authentication logic provided by {{product_name}}. It takes the configuration object with the following values for the single page application defined in the {{product_name}} console. You can copy these values from the {{product_name}} console.
+
+| Parameter | Description | Example |
+|-----------------------|----------------------------------------------------------------------------------------------------------------------|-----------------------------------|
+| signInRedirectURL | The URL to redirect the user to after successfully signing in. This URL should be an absolute URL and only accessible to authenticated users. | `http://localhost:5173` |
+| signOutRedirectURL | The URL to redirect the user to after signing out. This should be an absolute URL and should be accessible without authentication. | `http://localhost:5173/login` |
+| clientID | The client ID of the created OIDC application | - |
+| baseUrl | The base URL of the Identity Provider API. This depends on the identity provider you are using. For {{product_name}}, this can be obtained from your application settings in the {{product_name}} console. | `https://www.asgardeo.io/t/` |
+| scope | Specifies the required application scopes as a list. In this guide, we need access to user details, so we will request the 'profile' scope. | `[ "profile" ]` |
+
+!!! Info
+
+ If you’re familiar with OAuth2 or OIDC, you might notice that there’s no client secret involved here. This is because, according to the OAuth2 specification, our React app is classified as a public client. Since it runs on user devices and cannot securely store credentials, the Identity Provider (IdP) should not authenticate public clients before issuing access tokens. The {{product_name}} SDK addresses this by implementing the PKCE (Proof Key for Code Exchange) extension, which helps mitigate the security risks associated with public clients
+
+Here’s a brief overview of what `` provides:
+
+* **Context Management:** It creates a context that holds the authentication state and methods to handle authentication actions like logging in, logging out, and checking the user's authentication status.
+* **Session Handling:** `` manages user sessions, including token storage and retrieval, token refresh, and user session expiration handling.
+* **Easy Access to Authentication:** By wrapping your app with ``, any component within your app can easily access authentication details and actions using hooks like useAuthContext.
+* **Initialization and Configuration:** It initializes the SDK with the necessary configuration, such as client ID, server endpoints, and other authentication settings.
diff --git a/en/asgardeo/docs/complete-guides/react/introduction.md b/en/asgardeo/docs/complete-guides/react/introduction.md
new file mode 100644
index 0000000000..c04b09ec27
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/introduction.md
@@ -0,0 +1,43 @@
+---
+template: templates/complete-guide.html
+heading: Introduction
+read_time: 2 mins
+---
+React is a widely used JavaScript library designed for creating dynamic single-page apps (SPAs). It enables developers to build responsive interfaces by breaking down complex UIs into reusable components. Unlike traditional UI technologies, React updates specific parts of the page without re-rendering the entire page, thanks to its virtual DOM. This capability makes React popular for developing SPAs.
+
+Implementing login functionality in your React app is essential for managing user access, personalizing user experiences, and securing the app. It enhances user experience, protects user data, boosts engagement, and helps ensure regulatory compliance.
+
+
+## Learning objectives
+
+This guide will walk you through everything you need to know about securing React apps, including implementing user login in your React app, integrating it with an Identity Provider (IdP) to make the login process simple and secure, and general guidelines to protect your end users. It also covers how to make secure API calls to an OAuth2-protected API within your React app.
+
+In this guide, you will:
+
+* Register an application in {{product_name}}
+* Create a React app
+* Install Asgardeo React SDK
+* Add login and logout to your app
+* Display logged in user detail
+* Securing routes within the app
+* Accessing protected API from your React app
+* Managing tokens in your React app
+
+
+!!! tip "Tip"
+
+ This guide takes approximately 60 minutes to complete and covers everything required to add user login and secure your React apps. If you’re looking for a shorter guide, try the [React Quick Start guide](https://is.docs.wso2.com/en/latest/quick-starts/react/){:target="_blank"}, which takes around 15 minutes to complete.
+
+
+!!! tip "Tip"
+
+ If you are already familiar with the concepts discussed in the guide, you can use the Asgardeo React template to bootstrap your application by running the following command.
+
+ ```bash
+
+ npx tmplr --dir my-vite-react-app asgardeo/asgardeo-vite-react-template
+
+ ```
+ The Asgardeo React template generates a ready-made React sample app with pre-configured login and logout capabilities, helping you kick-start your project in just 2 minutes.
+
+ All you need is a `client_id`, which you can obtain by registering a **Single Page Application** in {{product_name}}.
diff --git a/en/asgardeo/docs/complete-guides/react/manage-tokens-in-React-apps.md b/en/asgardeo/docs/complete-guides/react/manage-tokens-in-React-apps.md
new file mode 100644
index 0000000000..ae33c5612a
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/manage-tokens-in-React-apps.md
@@ -0,0 +1,135 @@
+---
+template: templates/complete-guide.html
+heading: Manage tokens in React apps
+read_time: 2 min
+---
+
+## Token Validation
+
+A key principle of security tokens is that the receiver must first validate the token. This involves checking the authenticity of the token issuer, ensuring the token meets validity criteria such as expiration time, and confirming that the receiver is authorized to use the token. The Asgardeo React SDK handles token validation automatically as part of its authentication and session management process to ensure that users have valid and unexpired tokens when accessing protected resources.
+
+When a user signs in, the Asgardeo React SDK acquires an access token (and often an ID token) from {{product_name}}. The access token is by default an opaque token and the ID token is in the form of JSON Web Tokens (JWTs). The SDK automatically validates the token when it is obtained. This involves several checks:
+
+- **Signature Validation:** The SDK verifies the JWT's signature using the public key retrieved from {{product_name}} JWKS endpoint. This ensures that the token has been issued by a trusted authority and has not been tampered with.
+
+- **Expiration Check:** The SDK checks the `exp` (expiration) claim in the token to ensure it has not expired. Tokens are time-bound, and once the expiration time is reached, the token is considered invalid.
+
+- **Issuer Validation:** The SDK verifies that the `iss` (issuer) claim in the token matches the expected issuer URL, which is typically the base URL specified in the `authConfig`.
+
+- **Audience Validation:** The SDK checks the aud (audience) claim to ensure the token is intended for your application (identified by the `clientID` in your `authConfig`).
+
+If the token is close to being expired, the SDK will automatically attempt to renew the token by performing a silent sign-in (explained below). This helps maintain a seamless user experience without requiring the user to re-authenticate frequently. If the token has already expired and cannot be renewed silently, the user will be redirected to the login page to obtain a new token.
+
+## Token Persistence
+
+In the Asgardeo React SDK, the state storage mechanism determines where the authentication state, tokens, and other related data are stored. By default, Asgardeo React SDK uses session storage, but you can configure the SDK to use other storage options like local storage or even a web worker.
+
+You can specify the storage mechanism in the authConfig object using the storage property. Here's how you can configure it for different storage types.
+
+- **Local Storage:** localStorage stores data across browser sessions, meaning the data persists even after the browser is closed and reopened.
+
+```javascript
+
+const authConfig = {
+ // other configs
+ storage: "localStorage"
+}
+
+```
+
+- **Session Storage:** sessionStorage stores data for the duration of the page session. The data is cleared when the page session ends (e.g., when the tab is closed).
+
+```javascript
+
+const authConfig = {
+ // other configs
+ storage: "sessionStorage"
+}
+
+
+```
+
+- **Web Worker:** Using a web worker allows state to be managed in a separate thread, which can be beneficial for performance and security.
+
+```javascript
+
+const authConfig = {
+ // other configs
+ storage: "webWorker"
+}
+
+```
+
+Compared to other methods for persisting tokens, web workers are the most secure option, due to the following reasons.
+
+- **Performance**: Web workers run in a separate thread from the main JavaScript execution, offloading tasks like handling authentication state, which reduces the load on the main thread and leads to smoother UI interactions.
+
+- **Security:** Operating in isolation from the DOM, web workers reduce the risk of cross-site scripting (XSS) attacks by keeping sensitive authentication data secure.
+
+- **Asynchronous** Task Management: Web workers enhance the handling of asynchronous tasks, such as token renewal or data fetching, without blocking the main thread.
+
+- **Scalability:** By enabling parallelism, web workers make applications more responsive and better equipped to handle multiple concurrent operations.
+
+## Initiate Logout
+
+The Asgardeo React SDK provides a simple approach to handle user logout from your app. When a user logs out, the SDK ensures that both the local session and the session on the {{product_name}} are terminated, ensuring a complete and secure logout process and you don’t need to worry on cleanup activities
+
+When a user initiates log out, the following steps typically occur.
+
+- **Local Session Termination:** The SDK clears any locally stored credentials, such as the access token and the ID token, which are used to maintain the user's authentication state within the application. This effectively logs the user out of the application locally.
+
+- **Redirection to {{product_name}} for sign out:** After clearing the local session, the SDK redirects the user to the sign-out endpoint of your {{product_name}} organization. This ensures that the user is also signed out globally from {{product_name}}. It’s particularly important in single sign-on (SSO) scenarios where the user might be logged into multiple applications under the same identity.
+
+- **Post Sign-Out Redirection:** Once the global sign-out is complete, the user is redirected back to a specified URL, usually the application's homepage or a custom logout page, which is configured in the SDK's authConfig under signOutRedirectURL.
+
+## Silent Sign In
+
+Silent login allows an app to check if a user is already authenticated, either through a session cookie or a token stored in the browser, and re-authenticate automatically in the background. To implement silent sign-in using the Asgardeo React SDK, you can leverage the library's built-in support for token renewal and session management. Here's how you can do it:
+
+- **Configure the Silent Sign-In:** Ensure that your `authConfig` is set up to allow silent sign-in. You need to configure the prompt parameter to `none` when initiating a silent sign-in request. This instructs the identity provider to not display any login prompts and to rely on existing sessions instead.
+
+- **Use the SDK’s Built-in Functionality:** The Asgardeo React SDK typically handles silent token renewal automatically if the configuration is set correctly. When the access token is about to expire, the SDK will attempt to renew it silently in the background.
+
+- **Handling Token Expiry:** In your React components, you can handle token expiry by checking the authentication state and initiating a silent sign-in if the user’s session is still valid but the token has expired.
+
+```javascript
+
+import { AuthProvider, useAuthContext } from "@asgardeo/auth-react";
+
+
+const authConfig = {
+ signInRedirectURL: "http://localhost:5173",
+ signOutRedirectURL: "http://localhost:5173",
+ clientID: "",
+ baseUrl: "https://api.asgardeo.io/t/",
+ scope: ["openid", "profile"],
+ enableSilentSignIn: true // Enable silent sign-in
+};
+
+
+const App = () => {
+ const { state, signIn } = useAuthContext();
+
+
+ React.useEffect(() => {
+ if (!state.isAuthenticated) {
+ signIn({ prompt: "none" }).catch(() => {
+ // Handle silent sign-in failure
+ });
+ }
+ }, [state.isAuthenticated, signIn]);
+
+
+ return (
+
+ {/* App content */}
+
+ )
+}
+
+
+export default App;
+useAuthContext
+
+
+```
diff --git a/en/asgardeo/docs/complete-guides/react/next-steps.md b/en/asgardeo/docs/complete-guides/react/next-steps.md
new file mode 100644
index 0000000000..60bb2d0f7f
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/next-steps.md
@@ -0,0 +1,55 @@
+---
+template: templates/complete-guide.html
+heading: Next Steps
+read_time: 1 min
+---
+This guide you just have completed, covered the adding user login for React apps by integrating with an Identity Provider (IdP) and additional use cases such making calls to an OAuth2-protected API.
+
+!!! tip "Tip"
+
+ As you are now familiar with the concepts discussed in the guide, you can use the Asgardeo React template to bootstrap your application by running the following command.
+
+ ```bash
+
+ npx tmplr --dir my-vite-react-app asgardeo/asgardeo-vite-react-template
+
+ ```
+ The Asgardeo React template generates a ready-made React sample app with pre-configured login and logout capabilities, helping you kick-start your project in just 2 minutes.
+
+ All you need is a `client_id`, which you can obtain by registering a **Single Page Application** in {{product_name}}.
+
+
+
+
+
+
+Now that your React application is secured with authentication features integrated, It is time to explore the additional features {{product_name}} offers to make the login flow more diverse and secure.
+
+- [Multi factor authentication](https://wso2.com/asgardeo/docs/guides/authentication/mfa/){:target="_blank"}
+- [Passwordless authentication](https://wso2.com/asgardeo/docs/guides/authentication/passwordless-login/){:target="_blank"}
+- [Self registration](https://wso2.com/asgardeo/docs/guides/user-accounts/configure-self-registration/){:target="_blank"}
+- [Login UI customization](https://wso2.com/asgardeo/docs/guides/branding/){:target="_blank"}
diff --git a/en/asgardeo/docs/complete-guides/react/prerequisite.md b/en/asgardeo/docs/complete-guides/react/prerequisite.md
new file mode 100644
index 0000000000..e2f83d30b0
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/prerequisite.md
@@ -0,0 +1,18 @@
+---
+template: templates/complete-guide.html
+heading: Prerequisite
+read_time: 30 secs
+---
+
+## Before you start, ensure you have the following:
+
+* About 60 minutes
+* {{product_name}} account
+* [Node.js](https://nodejs.org/en/download/package-manager){:target="_blank"} v18+ and npm
+* A favorite text editor or IDE
+
+
+!!! note "Note"
+
+ You need to have installed [Node.js](https://nodejs.org/en/download/package-manager){:target="_blank"} v18+ and npm (which comes inbuilt with Node) to run this sample. Although Node.js is primarily a server-side language,it needs to have been installed to manage dependencies and run scripts for our project.
+
diff --git a/en/asgardeo/docs/complete-guides/react/register-an-application.md b/en/asgardeo/docs/complete-guides/react/register-an-application.md
new file mode 100644
index 0000000000..65b8cd7112
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/register-an-application.md
@@ -0,0 +1,38 @@
+---
+template: templates/complete-guide.html
+heading: Register an application in Asgardeo
+read_time: 2 min
+---
+
+First unless you already have done that, you need to create an organization in {{product_name}} and register your application as a single page application.
+
+* Sign up for a [free {{product_name}} account](https://wso2.com/asgardeo/docs/get-started/create-asgardeo-account/){:target="_blank"}
+* Sign into {{product_name}} console and navigate to **Applications > New Application.**
+* Select Single Page Application
+
+![Select Single Page Application]({{base_path}}/complete-guides/react/assets/img/image5.png){: width="600" style="display: block; margin: 0;"}
+
+Next, complete the wizard popup by providing a suitable name and an authorized redirect URL.
+
+!!! Example
+ name: is-react
+
+ Authorized redirect URL: http://localhost:5173*
+
+![Register a new application]({{base_path}}/complete-guides/react/assets/img/image8.png){: width="600" style="display: block; margin: 0;"}
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use [http://localhost:5173](http://localhost:5173){:target="_blank"}, as the sample app will be accessible at this URL.
+
+
+
+You will need the following information available in the Quick Start tab of your app or the Quickstart guide under the React SDK for the `AuthProvider` config.
+
+* Client ID
+* Base URL
+* Redirect URL
+
+![Quick start guide]({{base_path}}/complete-guides/react/assets/img/image9.png){: width="600" style="display: block; margin: 0;"}
+
+In this step, we have ve registered our React app as an application in the {{product_name}} console and generated the required metadata. Next, we will create a React app using Vite.
diff --git a/en/asgardeo/docs/complete-guides/react/securing-routes-within-the-app.md b/en/asgardeo/docs/complete-guides/react/securing-routes-within-the-app.md
new file mode 100644
index 0000000000..f2d22cb37d
--- /dev/null
+++ b/en/asgardeo/docs/complete-guides/react/securing-routes-within-the-app.md
@@ -0,0 +1,131 @@
+---
+template: templates/complete-guide.html
+heading: Securing Routes within the app
+read_time: 2 min
+---
+
+In a React app, routes define the paths within the application that users can navigate to, linking URLs to specific components. Securing routes is essential to protect sensitive data, prevent unauthorized access, and ensure that only authenticated users can access certain parts of the application. In this section, let’s look at how we can secure routes using Asgardeo React SDK
+
+The Asgardeo SDK provides multiple approaches to secure routes in your application. Here we will demonstrate how to secure routes in a single-page React app using [React Router v6](https://reactrouter.com/en/main){:target="_blank"} , the most popular routing library for React. The same approach can be applied to other routing libraries such as [TanStack Router](https://tanstack.com/router/latest){:target="_blank"} and [Wouter](https://github.com/molefrog/wouter){:target="_blank"}, etc.
+
+## Using ``
+
+Asgardeo React SDK provides the `SecureApp` component, using which you can wrap the whole app or a part of the app that needs to have secure access. Then all the views wrapped with the SecureApp component are not accessible to an unauthenticated user.
+
+```javascript
+
+
+ }
+ onSignIn={ onSignInFunction }
+ overrideSignIn={ overrideSignInFunction }
+ >
+
+
+
+
+```
+
+In the above example, the `SecureApp` component wraps the entire App component, restricting all unauthorized users from accessing any part of our React application. It displays a fallback UI component while the authentication status is being resolved, and accepts a callback function to trigger after the sign in is successful.
+
+## Using ``
+
+`AuthenticatedComponent` is another component provided by the Asgardeo React SDK to conditionally display UI elements based on the user's authentication status. You can use this to implement secure routes with react router in our app.
+
+```javascript
+
+import { AuthProvider } from '@asgardeo/auth-react'
+import { BrowserRouter as Router, Routes, Route } from 'react-router-dom'
+import LoginPrompt from './components/login-prompt'
+import Home from './pages/home'
+import Dashboard from './pages/dashboard'
+import './App.css'
+
+const config = {
+ signInRedirectURL: "http://localhost:5173",
+ signOutRedirectURL: "http://localhost:5173",
+ clientID: "0Fo7kLavZtHAVtXRr1zzpjwzeBMa",
+ baseUrl: "https://api.asgardeo.io/t/pavindu119",
+ scope: [ "openid","profile" ]
+}
+
+function App() {
+
+ return (
+ Initializing...}>
+
+
+ } />
+
+
+
+ }
+ />
+
+
+
+ )
+}
+
+export default App
+
+```
+
+This code snippet defines a route in a React application using the Route component from react-router-dom. It specifies that when the user navigates to the /dashboard path, the AuthenticatedComponent should be rendered. Let’s break down the code to understand what’s going on behind the scenes.
+
+- `path="/dashboard"`: This sets the URL path for this route. When the user visits `/dashboard`, the specified component will be rendered.
+
+- `element={...}`: defines the component(s) that will be rendered for this route. In this case, it’s the Dashboard UI view wrapped with AuthenticatedComponent.
+
+- `AuthenticatedComponent`: This is a React component provided by the Asgardeo React SDK that checks if the user is authenticated. It wraps around the Dashboard component to secure it.
+
+- `fallbackComponent={LoginPrompt}`: If the user is not authenticated, the AuthenticatedComponent will render the LoginPrompt component instead of the Dashboard component, prompting the user to log in.
+
+- ``: This is the main component that will be rendered if the user is authenticated and has access to the /dashboard route.
+
+## Bring your own implementation
+
+If you prefer to have full control over how the app routes should be secured—for example, if you want to run custom application logic before enabling or disabling a route—you can also build a completely custom logic using the primitives provided by the Asgardeo React SDK out of the box.
+
+```javascript
+
+const App = () => {
+
+ const ProtectedRoute = ({ children }: { children: ReactNode }) => {
+
+
+ const { state } = useAuthContext();
+
+
+ if (!state.isAuthenticated) {
+ return ;
+ }
+
+
+ return children;
+ };
+
+
+ return (
+
+
+
+
+ }
+ />
+ } />
+ } />
+
+ )
+};
+
+
+```
+
+In this step, we looked into how to secure component routes within a React app. Next, we will try to access a protected API from our React app, which is a common requirement for SPAs.
diff --git a/en/asgardeo/docs/concepts/api-security.md b/en/asgardeo/docs/concepts/api-security.md
new file mode 100644
index 0000000000..3072b49480
--- /dev/null
+++ b/en/asgardeo/docs/concepts/api-security.md
@@ -0,0 +1 @@
+{% include "../../../includes/concepts/api-security.md" %}
\ No newline at end of file
diff --git a/en/asgardeo/docs/concepts/customer-iam.md b/en/asgardeo/docs/concepts/customer-iam.md
new file mode 100644
index 0000000000..8650f11be2
--- /dev/null
+++ b/en/asgardeo/docs/concepts/customer-iam.md
@@ -0,0 +1 @@
+{% include "../../../includes/concepts/customer-iam.md" %}
\ No newline at end of file
diff --git a/en/asgardeo/docs/concepts/workforce-iam.md b/en/asgardeo/docs/concepts/workforce-iam.md
new file mode 100644
index 0000000000..47986e9a8d
--- /dev/null
+++ b/en/asgardeo/docs/concepts/workforce-iam.md
@@ -0,0 +1 @@
+{% include "../../../includes/concepts/workforce-iam.md" %}
\ No newline at end of file
diff --git a/en/asgardeo/docs/guides/authentication/mfa/add-iproov-login.md b/en/asgardeo/docs/guides/authentication/mfa/add-iproov-login.md
index 51aa24201a..7b62d386b2 100644
--- a/en/asgardeo/docs/guides/authentication/mfa/add-iproov-login.md
+++ b/en/asgardeo/docs/guides/authentication/mfa/add-iproov-login.md
@@ -20,15 +20,13 @@ Follow the steps below to register your service provider in the iPortal.
2. Click **Create a service provider**.
-3. Click **Create a service provider**.
+3. Enter a value for **Service provider name**.
-4. Enable a value for **Service provider name**.
+4. Complete the service provider details form and click **Create** to create the service provider.
-5. Complete the service provider details form and click **Create** to create the service provider.
+5. Select your application from the **Choose an App** menu and note down the App ID.
-6. Select your application from the **Choose an App** menu and note down the App ID.
-
-7. After you create the service provider, you will receive the following details:
+6. After you create the service provider, you will receive the following details:
- **OAuth username**
- **OAuth password**
- **API key**
@@ -36,7 +34,7 @@ Follow the steps below to register your service provider in the iPortal.
## Register iProov in Asgardeo as a connection
-Follow the steps below to register HYPR as a connection in Asgardeo.
+Follow the steps below to register iProov as a connection in Asgardeo.
1. On the Asgardeo Console, go to **Connections**.
@@ -75,10 +73,6 @@ Follow the steps below to register HYPR as a connection in Asgardeo.
API Secret
Provide the API secret obtained from the service provider created in iProov.
-
-
Enable Progressive Enrollment
-
Enable this to allow users to enroll with iProov during login.
-
## Enable iProov login
@@ -90,7 +84,7 @@ To enable iProov login for your application:
1. On the Asgardeo Console, go to **Applications**.
-2. Go to the **Sign-in Method** tab of the application and add iProov login from your preferred editor:
+2. Go to the **Login Flow** tab of the application and add iProov login from your preferred editor:
=== "Visual Editor"
To add iProov login using the Visual Editor:
diff --git a/en/asgardeo/docs/guides/branding/localization-in-asgardeo.md b/en/asgardeo/docs/guides/branding/localization.md
similarity index 100%
rename from en/asgardeo/docs/guides/branding/localization-in-asgardeo.md
rename to en/asgardeo/docs/guides/branding/localization.md
diff --git a/en/asgardeo/docs/guides/users/attributes/manage-attributes.md b/en/asgardeo/docs/guides/users/attributes/manage-attributes.md
index cb8fca75ec..89162bc999 100644
--- a/en/asgardeo/docs/guides/users/attributes/manage-attributes.md
+++ b/en/asgardeo/docs/guides/users/attributes/manage-attributes.md
@@ -1,2 +1 @@
-{% set attribute_path = "**User Attributes & Stores**" %}
{% include "../../../../../includes/guides/users/attributes/manage-attributes.md" %}
\ No newline at end of file
diff --git a/en/asgardeo/docs/guides/users/manage-administrators.md b/en/asgardeo/docs/guides/users/manage-administrators.md
index f2c2548d96..010e330599 100644
--- a/en/asgardeo/docs/guides/users/manage-administrators.md
+++ b/en/asgardeo/docs/guides/users/manage-administrators.md
@@ -3,83 +3,68 @@
This guide walks you through the steps of managing an administrator account. If you are the owner or an existing administrator in the organization, you can onboard new administrators or delete existing administrator accounts.
!!! note
- You cannot manage the user profiles of other administrators or update their passwords from the Asgardeo Console. Administrators must [manage their own profiles and passwords]({{base_path}}/guides/your-asgardeo/asgardeo-self-service/#change-password) using the **My Account** portal.
+ You cannot manage the user profiles of other administrators or update their passwords from the Asgardeo Console. Administrators must manage their own profiles and passwords using the [My Account portal]({{base_path}}/guides/your-asgardeo/asgardeo-self-service/).
## Onboard an administrator
There are two ways to onboard an administrator:
- An administrator can onboard new administrators by [sending an email invitation](#invite-an-external-administrator).
-- An administrator can [assign existing users administrative privileges](#assign-admin-privileges-to-users).
+- An administrator can [assign administrative privileges to existing users](#assign-admin-privileges-to-users).
### Invite an external administrator
-Let's look at how administrators can onboard another administrator by sending an email invitation.
-To onboard an administrator:
+Existing administrators can onboard other administrators by sending them email invitations to join the organization. To do so,
1. On the Asgardeo Console, go to **Console Settings** > **Administrators**.
-2. Click **Add Administrator** and provide the required details.
+2. Click **Add Administrator** and provide the following details.
!!! note
- Note that if your organization allows you to [assign admin privileges to business users](#assign-admin-privileges-to-users), you will see the following options when you click **Add Administrator**.
-
- ![Add administrator dropdown]({{base_path}}/assets/img/guides/users/add-administrator-dropdown.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
-
- You need to select **Invite admins to Asgardeo** from this list to proceed with inviting an external admin.
-
- ![Add administrator user]({{base_path}}/assets/img/guides/users/add-administrator.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+ If you have enabled the option to [assign admin privileges to users](#assign-admin-privileges-to-users), you may proceed to invite external admins by clicking *Add Administrator* > *Invite Admins to Asgardeo*.
-
Field name
-
Description
-
-
-
Email Address
-
Provide the email address to which the invitation email should be sent. This email address will be used as the admin's username in Asgardeo. Note that a username is always unique to the organization, and you can't change it once it is created.
+
Email Address
+
The invitation will be sent to this email address. Additionally, this email address will be used as the username of this administrator.
+ Usernames are always unique to an organization. Once created, they cannot be modified.
+
-
Role
-
The Administrator role is assigned by default. For details on the available user roles and the permissions assigned to them, see [Asgardeo User Roles]({{base_path}}/references/user-management/user-roles/).
+
Role
+
Users can be assigned one or more default roles. For details on the available user roles and the permissions assigned to them, see [Asgardeo User Roles]({{base_path}}/references/user-management/user-roles/).
3. Click **Invite** to send the invitation.
-
-The administrator can access the Asgardeo Console by accepting the invitation and setting a password for the new administrator account.
+The external administrator can join the organization by accepting the invitation and setting a password for the new administrator account.
### Assign admin privileges to users
-You can assign admin privileges to existing business users only if it is allowed in your organization. Follow the instructions given below.
+This option has to be enabled for the organization. If enabled, administrators can assign the administrator role to existing non-privileged users.
-First, configure administrator settings for the organization:
+To enable this option,
1. On the Asgardeo Console, go to **Console Settings** > **Administrators**.
-2. Click the settings icon next to **+ Add Administrator** to open the **Administrator Settings** page.
-
-3. Switch on the **Enable users to manage the organization** toggle.
+2. Click the settings icon next to **Add Administrator** to open the **Administrator Settings** page.
- ![Assign an existing user as an admin]({{base_path}}/assets/img/guides/users/enable-users-to-manage-organizations.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+3. Turn on the **Enable users to manage the organization** toggle.
-4. Go back to the **Administrators** tab and see that the **+ Add Administrator** list is updated as follows:
+4. Go back to the **Administrators** tab and click **Add Administrator** to see a list with two options as follows:
- ![Add administrator dropdown]({{base_path}}/assets/img/guides/users/add-administrator-dropdown.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+ ![Add administrator dropdown]({{base_path}}/assets/img/guides/users/add-administrator-dropdown.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
-Now, let's assign admin privileges to a user:
+To assign users the administrator role,
-1. On the **Console Settings** > **Administrator** page, click **+Add Administrator > Assign admins from users**.
-2. Select the user you want to add as an administrator and click **Add**.
+1. On the **Console Settings** > **Administrators** page, click **+Add Administrator > Add Existing User**.
+2. Select the user's username and the **Administrator** role and click **Add**.
The new administrator can now access the Asgardeo Console using the following URL:
-!!! note
- Be sure to replace `{org_name}` with the relevant organization name.
-
```
-https://console.asgardeo.io/t/{org_name}
+https://console.asgardeo.io/t/{organization_name}
```
!!! note
@@ -88,7 +73,7 @@ https://console.asgardeo.io/t/{org_name}
## View administrators
To view the administrators of your organization:
-On the Asgardeo Console, go to **Administrators**. You will see the list of administrators presented in two tabs as follow.
+On the Asgardeo Console, go to **Console Settings > Administrators**. You will see the list of administrators presented in two tabs as follow.
@@ -96,18 +81,17 @@ On the Asgardeo Console, go to **Administrators**. You will see the list of admi
This includes administrators whose identity is managed by Asgardeo.
-
{org_name} organization
+
{organization_name} organization
This includes administrators whose identity is managed by the {org_name} organization.
## Delete an administrator
-!!! warning Before you begin
- Note the following:
+!!! warning "Before you begin"
- - If the administrator you delete is a business user with admin privileges, you will only be revoking the administrator privileges from the user. Deleting this administrator does not delete the user account.
- - If the administrator is not a business user, you will be deleting the user account from the organization. This action is irreversible.
+ - If you delete an exiting user who was assigned to the administrator role, you will only be revoking the administrator privileges from that user. Deleting this administrator does not delete the user account.
+ - If you delete other administrators, you will be deleting the user account from the organization. This action is irreversible.
To delete an administrator:
diff --git a/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/index.md b/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/index.md
deleted file mode 100644
index da7608f621..0000000000
--- a/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Migrate users to Asgardeo
-
-Organization owners may need to migrate users from an existing Identity Provider (IdP) to Asgardeo for the following reasons:
-
-- To combine users of multiple systems to a single IdP for proper user management.
-- To reorganize, restructure, and simplify user data storage.
-- To combine user data storages to ease centralized user management and to facilitate company acquisitions and mergers.
-- To move or separate identity data due to geopolitical, data protection, compliance, and regulatory reasons.
-- To improve identity management by providing increased security, scalability, and reduced maintenance costs.
-
-Follow the guides in this section to learn how to [migrate user accounts to Asgardeo]({{base_path}}/guides/users/migrate-users-to-asgardeo/migrate-users/) and [migrate user passwords to Asgardeo]({{base_path}}/guides/users/migrate-users-to-asgardeo/migrate-passwords/).
\ No newline at end of file
diff --git a/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/migrate-passwords.md b/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/migrate-passwords.md
deleted file mode 100644
index 4d163a2b1a..0000000000
--- a/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/migrate-passwords.md
+++ /dev/null
@@ -1,258 +0,0 @@
-# Migrate passwords to Asgardeo
-
-You may use one of the following two ways to migrate user passwords to Asgardeo.
-
-## Migrate with password reset
-
-This method involves the least administrative effort but causes the most friction for users. With a password reset, users will receive an email prompting them to set a password for their new Asgardeo accounts. Until they set a password, their user accounts will remain locked to prevent unauthorized access. Additionally, this method allows you to immediately terminate operations on your previous IdP once the user accounts are successfully migrated to Asgardeo.
-
-If you wish to migrate user passwords using this method, inform the Asgardeo team along with your request to [migrate users](#migrate-users).
-
-## Migrate with on-demand silent migration
-
-Compared to password reset method above, on-demand silent password migration involves more effort to set up but provides the user with a seamless password migration experience. The following are the high level steps involved with this method.
-
-1. The user attempts to log in to the application.
-
-2. The application redirects the user to the Asgardeo login screen.
-
-3. The user enters the usual credentials for the legacy IdP.
-
-4. If Asgardeo has already migrated the user's password, the user is logged in. If not, Asgardeo makes an authentication request to the legacy IdP with the user provided credentials.
-
-5. Asgardeo redirects the user to a waiting page until the legacy IdP completes the authentication.
-
-6. Once complete, the user is taken back to the application and Asgardeo silently migrates the password for the user.
-
-7. The user is successfully logged in and may now continue using the usual credentials to log in to the application with Asgardeo.
-
-!!! note
-
- If you wish to migrate users with this method, it is crucial to note the following:
-
- - The legacy IdP should run alongside Asgardeo for a set period to facilitate user migration.
- - Have a contingency plan to migrate any accounts that were not migrated while the legacy IdP is active.
- - Unmigrated users must contact the Asgardeo organization administrators to initiate a password reset process, facilitating a smooth and complete transition to Asgardeo.
-
-The following guides go into detail on implementing on-demand silent password migration.
-
-### How it works?
-
-The following diagram provides a general idea on the components involved with the on-demand silent password migration.
-
-![On-demand silent user password migrations]({{base_path}}/assets/img/guides/users/migrate-users/silent-user-migration.png)
-
-Let's look at the diagram in detail:
-
-1. The user starts the authentication by entering the credentials used for the legacy IdP.
-2. If Asgardeo has not already migrated the user account,
-
- - user's login fails.
- - Asgardeo attempts to find a user corresponding to the provided login identifier.
- - If found, Asgardeo then checks for the user's migration status value which is stored in a user attribute.
-
-3. If user's migration status is not set to true,
-
- - Asgardeo starts authentication with the legacy IdP by invoking the **start authentication API**.
- - This API responds with a unique ID for the process called the `contextID`.
- - The user is redirected to a waiting page until external authentication completes.
-
- !!! note
-
- This API is part of an authentication service deployed in [Choreo](https://wso2.com/choreo/){target="_blank"}, WSO2's integration platform. The service is designed to facilitate authentication against the legacy IdP.
-
-4. The authentication service will then interact with the legacy IdP and attempt to authenticate the user. A result will be returned once authentication is complete.
-5. In the meantime, **the polling API**, another API of the authentication service, keeps polling to check if the authentication process is complete. This API uses the `contextID` returned in 3 to track the specific process.
-6. Once 4 completes, the polling API in 5 stops and the user is redirected back to the login page.
-7. Asgardeo then calls the **authentication status endpoint**, the third API of the authentication service, to retrieve the authentication result.
-8. If the result is a success, this means the user was successfully authenticated against the external IdP. Hence, Asgardeo will
-
- - migrate the user's password to Asgardeo.
- - set the migration status attribute of the user to true.
- - authenticate the user to the application.
-
-9. The user is seamlessly logged into the application without being prompted to enter the credentials again.
-
-### Prerequisites
-
-Before you begin, ensure the following are fulfilled.
-
-- [Migrate user accounts to Asgardeo]({{base_path}}/guides/users/migrate-users-to-asgardeo/migrate-users/).
-- Ensure your legacy IdP provides means to perform basic user authentication (i.e. username and password authentication). For example, a SCIM2/Me REST API endpoint that could be authenticated with username and password.
-- You need to have a Github repository to host the authentication service.
-- Download [Ballerina](https://ballerina.io/downloads/){target="_blank"}, the programming language used to define the external authentication service.
-
-### Step 1: Develop the authentication service
-
-In this section, we will develop an authentication service that will communicate with the legacy IdP to authenticate users.
-
-!!! note
- You may find a sample Ballerina authentication service [here](https://github.com/wso2/samples-is/tree/master/user-migration-samples/asgardeo/external-authentication-service){target="_blank"}.
-
-1. Create a new Ballerina package. Learn how to do so in the [Ballerina documentation](https://ballerina.io/learn/get-started/){target="_blank"}.
-
-2. Write a [RESTful service](https://ballerina.io/learn/write-a-restful-api-with-ballerina/){target="_blank"} that communicates with the legacy authentication system to perform user authentication. Your service should expose the following REST API endpoints.
-
- !!! tip
-
- External authentication may require additional processing time depending on the legacy IdP and network delays. Therefore it is recommended to perform the external authentication asynchronously without holding an active connection until the external authentication completes.
-
- - **Start authentication endpoint** - to initiate the authentication process with the legacy system. This endpoint should accept the request, return a response with a unique random identifier (preferably a UUID) and then start the external authentication process.
-
- - **Authentication status endpoint** - to retrieve and return the completed authentication result.
-
- - **Polling endpoint** - to return the completion status of the external authentication task. This should be an open endpoint that doesn’t require any authentication.
-
- !!! warning "Adding logs"
-
- We highly recommend adding sufficient logging when developing the REST service. However, ensure no sensitive information or Personally Identifiable Information (PII) are included in the logs.
-
-3. Commit your changes and push the code to your remote Github repository.
-
-### Step 2: Create and deploy the RESTful service in Choreo
-
-We will now deploy the developed authentication service in [Choreo](https://wso2.com/choreo/){target="_blank"}, WSO2's integration platform. To do so,
-
-1. Go to the [Choreo Console](https://console.choreo.dev/login){target="_blank"} and login with the SAME email address you used to create your Asgardeo organization.
-
- !!! note
-
- An organization with the same name as your Asgardeo organization will be created for you in Choreo.
-
-2. On the top of the Console, create a new project or select an existing one.
-
-3. On the left panel, select **Components** and click **Create**.
-
-4. On the **Select a type** tab, select **Service**.
-
- ![Select a type of component]({{base_path}}/assets/img/guides/users/migrate-users/create-a-component.png)
-
- !!! note
-
- Learn more about service components in the [Choreo documentation](https://wso2.com/choreo/docs/develop-components/develop-services/service-component-overview/){target="_blank"}
-
-5. Enter a name and description for your service.
-
-6. Click **Authorize with Github** and connect the relevant organization, repository and the branch for the developed authentication service in step 1.
-
-7. Select **Ballerina** to be the buildpack and select the Ballerina project directory from your Github repository.
-
- ![Enter details of the service component]({{base_path}}/assets/img/guides/users/migrate-users/service-details.png)
-
-8. Click **Create**.
-
-9. Build and deploy the service. See [Choreo documentation](https://wso2.com/choreo/docs/develop-components/develop-services/develop-a-service/#step-2-build-and-deploy){target="_blank"} for instructions.
-
- !!! note
-
- If you are using the sample authentication service, be sure to provide values for the necessary configurations before you deploy the service.
-
-10. As discussed earlier, the polling endpoint should be an open endpoint. Follow the steps below to configure this.
-
- 1. Go to **Deployment** and in the **Set up** card, click **Endpoint Configurations**.
-
- 2. In the window that appears, under **Permissions**, expand the polling endpoint and turn the **Security** toggle off.
-
- ![Make the polling endpoint open]({{base_path}}/assets/img/guides/users/migrate-users/polling-make-open-endpoint.png)
-
- 3. Click **Apply** to save the changes.
-
-11. On the left navigation, go to **Manage** > **Lifecycle** and click **Publish**.
-
-### Step 3: Create a Choreo application to consume the APIs
-
-After the RESTful service is deployed, follow the steps below to create an application in Choreo and subscribe it to the REST API. This application will later be used to integrate the REST APIs with the Asgardeo application.
-
-1. Sign in to the [Choreo Developer Portal](https://devportal.choreo.dev/){target="_blank"} with the same email address you used to log in to the Choreo Console in step 2.
-
-2. On the top navigation, go to **Applications** and click **Create Application**.
-
-3. Provide a name and a description for the application and click **Create**.
-
-4. On the left navigation, go to **Credentials** and click **Generate Credentials**.
-
-5. Take note of the generated consumer key and consumer secret as you will need it later.
-
-6. On the left navigation, go to **Subscriptions** and click **Add APIs**.
-
-7. Click **Add** corresponding to the API that you created in step 2.
-
-!!! note
-
- To learn more about applications in Choreo, refer to the [Choreo documentation](https://wso2.com/choreo/docs/consuming-services/manage-application/#create-an-application){target="_blank"}.
-
-
-### Step 4: Configure an attribute in Asgardeo to hold the migration status
-
-Asgardeo should have means to check whether a user's password is migrated or not. This can be achieved by creating a user attribute in Asgardeo to hold the migration status. To do so,
-
-1. On the Asgardeo Console, go to **User Attributes & Stores** > **Attributes** and click on **Attributes**.
-
-2. Click **New Attribute** and enter the following details:
-
-
-
-
Attribute name
-
is_migrated
-
-
-
Attribute Display Name
-
Password migration status
-
-
-
-3. Click **Finish** to create the attribute.
-
-### Step 5: Configure the login flow of the Asgardeo application
-
-You are now ready to configure your application for on-demand silent password migration. To do so,
-
-1. On the Asgardeo Console, click **Application**.
-
-2. Select the application and go to its **Login Flow** tab.
-
-3. Configure the login flow using your preferred editor:
-
- === "Classic Editor"
-
- To configure the login flow using the classic editor:
-
- 1. Click **Start with default configuration** or add the **Username & Password** authenticator to the first step of the flow.
-
- 2. Turn on Conditional Authentication by switching on the toggle.
-
- ![Configure with classic editor]({{base_path}}/assets/img/guides/users/migrate-users/migrate-users-classic.png)
-
- 3. Replace any existing code with this [conditional authentication script]({{base_path}}/guides/authentication/conditional-auth/on-demand-silent-password-migration-template/).
-
- === "Visual Editor"
-
- To configure the login flow using the visual editor:
-
- 1. Switch to the Visual Editor tab.
-
- 2. If **Username & Password** authentication is not set, go to **Predefined flows** > **Basic Login Flows** > **Add Basic Login** and select it to add to the login flow.
-
- 3. Turn on Conditional Authentication by switching on the toggle.
-
- ![Configure with visual editor]({{base_path}}/assets/img/guides/users/migrate-users/migrate-users-visual.png){: width="500"}
-
- 4. Replace any existing code with this [conditional authentication script]({{base_path}}/guides/authentication/conditional-auth/on-demand-silent-password-migration-template/).
-
-4. Click **Update** to save the changes.
-
-### Try it out
-
-Follow the steps below to try out on-demand silent password migration for a migrated user account.
-
-1. Access the application URL.
-
-2. Log in to Asgardeo with the user credentials used for the legacy IdP.
-
-3. If the user's password is not yet migrated, you'll be redirected to a waiting page as follows.
-
- ![Wait page]({{base_path}}/assets/img/guides/users/migrate-users/wait-page.png){: width="400"}
-
-4. Asgardeo will migrate the password and log the user in once the external authentication is successful.
-
-
\ No newline at end of file
diff --git a/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/migrate-users.md b/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/migrate-users.md
deleted file mode 100644
index dff76aafb2..0000000000
--- a/en/asgardeo/docs/guides/users/migrate-users-to-asgardeo/migrate-users.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Migrate user accounts to Asgardeo
-
-This guide explains how you may prepare and execute a user migration from another Identity Provider (IdP) to Asgardeo.
-
-## Prepare for migration
-
-Before migrating users to Asgardeo, organization owners must adequately plan and prepare for a smooth transition. This ensures that you identify the risks and challenges associated with the migration process beforehand. Below are the key steps to follow when planning your migration.
-
-- Assess company and legal requirements
-
- Ensure you are operating within the limits imposed by your company policies and regulations involving Personally Identifiable Information (PII) and other user data.
-
-- Assess current user data
-
- Conduct a comprehensive analysis of the existing user data in the legacy system. Determine the number of users, their roles, attributes and associated permissions. Clearly identify which user attributes are PII and which user attributes should remain confidential.
-
-- Define migration goals
-
- Clearly define the migration objectives and goals. Determine why you are migrating and what outcomes you aim to achieve. Decide on what types of users you will maintain in the new system, and the number of users belonging to each type. Also decide on what attributes you need to migrate to the new system. This will help you estimate the time required for the migration and optimally allocate resources.
-
-- Evaluate migration strategies
-
- Asgardeo facilitates one-time migration of user profiles. Once migrated, users' login credentials can be migrated through either a forced password reset or an on-demand silent password migration. Evaluate these strategies and determine the best option for your requirements.
-
-- Create a migration plan
-
- Prepare a comprehensive migration plan by considering the following aspects.
-
- - Identify how you want your users to experience the migration.
- - Identify the acceptable user impact.
- - Define the attribute mappings between the legacy system and Asgardeo. Consider the data types, data lengths, uniqueness, whether each attribute is required or optional and any necessary transformations before migrating to the new system.
- - Identify the risks and challenges associated with the migration process such as data loss, compatibility issues, service disruptions, etc.
- - Establish a clear migration timeline considering milestones, downtime windows and peak usage periods.
-
-- Test the migration plan
-
- Execute the migration plan over a realistic test data set. This will help reveal any issues that may arise during the migration process so that they may be addressed before the actual migration.
-
-With a clear and concise plan in place, you are ready to move on to the implementation.
-
-
-## Migrate user accounts
-
-Contact the Asgardeo team at **asgardeo-help@wso2.com** for support on migrating your existing user base to Asgardeo. Additionally, inform the team how you would like to [migrate user passwords]({{base_path}}/guides/users/migrate-users-to-asgardeo/migrate-passwords/).
-
-!!! note
- Make sure to request using the email address registered with an owner account or an administrator account.
\ No newline at end of file
diff --git a/en/asgardeo/docs/guides/users/migrate-users/index.md b/en/asgardeo/docs/guides/users/migrate-users/index.md
new file mode 100644
index 0000000000..b13831d3f2
--- /dev/null
+++ b/en/asgardeo/docs/guides/users/migrate-users/index.md
@@ -0,0 +1,2 @@
+{% set product_name = "Asgardeo" %}
+{% include "../../../../../includes/guides/users/migrate-users/index.md" %}
diff --git a/en/asgardeo/docs/guides/users/migrate-users/migrate-passwords.md b/en/asgardeo/docs/guides/users/migrate-users/migrate-passwords.md
new file mode 100644
index 0000000000..fb4bf55795
--- /dev/null
+++ b/en/asgardeo/docs/guides/users/migrate-users/migrate-passwords.md
@@ -0,0 +1,2 @@
+{% set product_name = "Asgardeo" %}
+{% include "../../../../../includes/guides/users/migrate-users/migrate-passwords.md" %}
diff --git a/en/asgardeo/docs/guides/users/migrate-users/migrate-users.md b/en/asgardeo/docs/guides/users/migrate-users/migrate-users.md
new file mode 100644
index 0000000000..849858b2ab
--- /dev/null
+++ b/en/asgardeo/docs/guides/users/migrate-users/migrate-users.md
@@ -0,0 +1,2 @@
+{% set product_name = "Asgardeo" %}
+{% include "../../../../../includes/guides/users/migrate-users/migrate-users.md" %}
diff --git a/en/asgardeo/docs/guides/users/user-stores/configure-a-user-store.md b/en/asgardeo/docs/guides/users/user-stores/configure-a-user-store.md
index 36b2c662b9..4a5b3f3d02 100644
--- a/en/asgardeo/docs/guides/users/user-stores/configure-a-user-store.md
+++ b/en/asgardeo/docs/guides/users/user-stores/configure-a-user-store.md
@@ -98,6 +98,9 @@ To configure a remote user store for your organization:
- `Username` - This attribute is used as the user identifier. Provide an attribute that identifies your user in your on-premise user store. For the best experience, use a username that satisfies validation rules in [Username Validation]({{base_path}}/guides/user-accounts/account-login/username-validation/) section.
- `User ID` - This attribute is used to uniquely identify a user entry. Provide an attribute that uniquely identifies a user entry in your user store.
+ Additionally, for Non-JDBC user stores, ensure that multiple email addresses and mobile numbers attributes are properly configured by following the instructions in the [Assign multiple email addresses and mobile numbers to
+ a user]({{base_path}}/guides/users/attributes/manage-attributes/#assign-multiple-email-addresses-and-mobile-numbers-to-a-user) section.
+
5. Click **Finish** to complete the registration.
## Set up the remote user store
diff --git a/en/asgardeo/docs/quick-starts/angular.md b/en/asgardeo/docs/quick-starts/angular.md
new file mode 100644
index 0000000000..d503a503ce
--- /dev/null
+++ b/en/asgardeo/docs/quick-starts/angular.md
@@ -0,0 +1,262 @@
+---
+template: templates/quick-start.html
+heading: Angular Quickstart
+description: Welcome to the Angular Quickstart guide! In this document, you will learn to build a Angular app, add user login and display user profile information using Asgardeo.
+what_you_will_learn:
+ - Create new Angular app
+ - Install angular-oauth2-oidc package
+ - Add user login and logout
+ - Display user profile information
+prerequisites:
+ - About 15 minutes
+ - {{product_name}} account
+ - Install a JS package manager
+ - Install Angular CLI
+ - A favorite text editor or IDE
+source_code: Angular App Sample
+
+whats_next:
+# - Try out {{ product_name }} complete React guide
+# - Try out {{product_name}} user onboarding complete guide for React
+# - Read security best practices for React app guide
+---
+## Configure an Application in {{ product_name }}
+
+- Sign into {{ product_name }} console and navigate to **Applications > New Application.**
+- Select **Single Page Application** and complete the wizard popup by providing a suitable name and an authorized redirect URL
+
+*Example:*
+
+- *Name - asgardeo-angular*
+- *Authorized redirect URL - http://localhost:4200*
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use`http://localhost:4200`, as the sample app will be accessible at this URL.
+
+!!! note
+
+ Make a note of the following values from the **Protocol** and **Info** tabs of the registered application. You will need them during the **Step 4**
+
+ - **`client-id`** from the **Protocol** tab.
+ - **`issuer`** from from the **Info** tab.
+
+## Create an Angular app
+
+Create an Angular app using Angular CLI.
+
+
+
+``` bash
+
+ ng new asgardeo-angular
+```
+
+!!! tip "Tip"
+ To run the command above, you need to have Angular CLI installed. You can install it using the following command.
+ === "npm"
+
+ ``` bash
+
+ npm install -g @angular/cli@17
+
+ ```
+ === "yarn"
+
+ ``` bash
+
+ yarn global add @angular/cli@17
+
+ ```
+
+ === "pnpm"
+
+ ``` bash
+
+ pnpm add -g @angular/cli@17
+
+ ```
+
+
+
+## Install angular-oauth2-oidc
+
+The [Angular OAuth2 OIDC SDK](https://www.npmjs.com/package/angular-oauth2-oidc){:target="_blank"} is a production-ready OIDC SDK that simplifies integrating {{product_name}} into your Angular applications. To get started, simply add the Angular OAuth2 OIDC SDK to the project. Make sure to stop the dev server started in the previous step.
+
+=== "npm"
+
+ ``` bash
+
+ npm install angular-oauth2-oidc
+
+ ```
+
+=== "yarn"
+
+ ``` bash
+
+ yarn add angular-oauth2-oidc
+
+ ```
+
+=== "pnpm"
+
+ ``` bash
+
+ pnpm add angular-oauth2-oidc
+
+ ```
+
+
+
+
+
+## Configure `AuthConfig` in your app
+
+The `AuthConfig` object holds the configuration necessary for connecting your app to {{product_name}}.
+
+Replace the content of `app.config.ts` file with the following code.
+
+!!! Important
+
+ Make sure to replace the placeholders in the following code with the **`client-id`** and **`issuer`** values you copied in **Step-1** during the application registration in the {{product_name}} console.
+
+ - ``
+ - ``
+
+```javascript title="app.config.ts"
+
+import { ApplicationConfig, APP_INITIALIZER } from '@angular/core';
+import { provideRouter } from '@angular/router';
+import { provideHttpClient } from '@angular/common/http';
+import { provideOAuthClient, OAuthService, AuthConfig } from 'angular-oauth2-oidc';
+import { routes } from './app.routes';
+
+export const authConfig: AuthConfig = {
+ issuer: '',
+ redirectUri: 'http://localhost:4200',
+ clientId: '',
+ responseType: 'code',
+ scope: 'openid profile email internal_login',
+ strictDiscoveryDocumentValidation: false,
+};
+
+function initializeOAuth(oauthService: OAuthService): () => Promise {
+ return () => {
+ oauthService.configure(authConfig);
+ return oauthService.loadDiscoveryDocumentAndTryLogin().then(() => { });
+ };
+}
+
+export const appConfig: ApplicationConfig = {
+ providers: [provideRouter(routes),
+ provideHttpClient(),
+ provideOAuthClient(),
+ {
+ provide: APP_INITIALIZER,
+ useFactory: initializeOAuth,
+ deps: [OAuthService],
+ multi: true
+ }
+ ]
+};
+
+
+```
+
+!!! Important
+
+ Make sure to add `strictDiscoveryDocumentValidation: false` parameter.
+
+## Add login and logout link to your app
+
+Angular uses services to access authentication data, and you can inject the `OAuthService` into your components to manage user authentication.
+
+The `OAuthService` provides methods for logging in and out, checking the authentication status, and retrieving access tokens.
+
+Replace the existing content of the `app.component.ts` file with following content.
+
+```javascript title="app.component.ts" hl_lines="16-28"
+
+import { Component } from '@angular/core';
+import { RouterOutlet } from '@angular/router';
+import { OAuthService } from 'angular-oauth2-oidc';
+import { CommonModule } from '@angular/common';
+
+@Component({
+ selector: 'app-root',
+ standalone: true,
+ imports: [RouterOutlet, CommonModule],
+ templateUrl: './app.component.html',
+ styleUrl: './app.component.css'
+})
+
+export class AppComponent {
+ title = 'asgardeo-angular';
+ isAuthorized = this.oAuthService.hasValidAccessToken();
+
+ constructor(private oAuthService: OAuthService) {
+
+ }
+
+ login() {
+ this.oAuthService.initLoginFlow();
+ }
+
+ logout() {
+ this.oAuthService.revokeTokenAndLogout();
+ }
+}
+
+```
+
+Next, replace the existing content of the `app.component.html` file with following content to add login and logout URLs.
+
+```html title="app.component.html"
+
+
+
+
+
+```
+
+
+
+
+
+Visit your app's homepage at [http://localhost:4200](http://localhost:4200).
+
+!!! Important
+
+ You need to create a test user in {{ product_name }} by following this [guide]({{ base_path }}/guides/users/manage-users/#onboard-single-user){:target="_blank"} to tryout login and logout features.
+
+## Display logged in user details
+
+Modified the code as below to see logged in user details.
+
+
+Add the `username()` function to the `app.component.ts` file to access the username attribute.
+
+```javascript title="app.component.ts" hl_lines="3-6"
+...
+
+ get username() {
+ var claims = this.oAuthService.getIdentityClaims();
+ if (!claims) return null;
+ return claims['username'];
+ }
+
+...
+```
+
+Modify the `app.component.html` file with the following code.
+
+```html title="app.component.html" hl_lines="2"
+
+
+
Hello {{ username }}!
+
+
+```
+
+
diff --git a/en/asgardeo/docs/quick-starts/nextjs.md b/en/asgardeo/docs/quick-starts/nextjs.md
new file mode 100644
index 0000000000..2bb2067362
--- /dev/null
+++ b/en/asgardeo/docs/quick-starts/nextjs.md
@@ -0,0 +1,304 @@
+---
+template: templates/quick-start.html
+heading: Next.JS Quickstart
+description: Welcome to the Next.js Quickstart guide! In this document, you will learn to build a Next.js app, add user login and display user profile information using Asgardeo.
+what_you_will_learn:
+ - Create new Next.js app
+ - Install Asgardeo provider for Auth.js
+ - Add user login and logout
+ - Display user profile information
+prerequisites:
+ - About 15 minutes
+ - Asgardeo account
+ - Install a JS package manager
+ - A favorite text editor or IDE
+# source_code: Next.js App Sample
+whats_next:
+ # - Try out {{ product_name }} complete React guide
+ # - Try out {{product_name}} user onboarding complete guide for React
+ # - Read security best practices for React app guide
+---
+## Configure an Application in {{ product_name }}
+
+- Sign into {{ product_name }} console and navigate to **Applications > New Application.**
+- Select **Traditional Web Application** and complete the wizard popup by providing a suitable name and an authorized redirect URL.(*Ensure that the protocol remains set to OpenID Connect (OIDC).)*
+
+*Example:*
+
+- *Name - asgardeo-nextjs*
+- *Authorized redirect URL - http://localhost:3000/api/auth/callback/asgardeo*
+
+
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use ` http://localhost:3000/api/auth/callback/asgardeo`, as the authorized redirect URL .
+
+!!! note
+
+ Make a note of the following values from the **Protocol** and **Info** tabs of the registered application. You will need them during the **Step 4**
+
+ - **`client-id`** from the **Protocol** tab.
+ - **`client-secret`** from the **Protocol** tab.
+ - **`issuer`** from from the **Info** tab.
+
+## Create a Next.js app
+
+Create your new Next.js app.
+
+=== "npm"
+
+ ``` bash
+ npx create-next-app@latest --typescript asgardeo-nextjs
+
+ cd asgardeo-nextjs
+
+ npm install
+
+ npm run dev
+ ```
+
+=== "yarn"
+
+ ``` bash
+ yarn create next-app --typescript asgardeo-nextjs
+
+ cd asgardeo-nextjs
+
+ yarn install
+
+ yarn dev
+ ```
+
+=== "pnpm"
+
+ ``` bash
+ pnpm create next-app --typescript asgardeo-nextjs
+
+ cd asgardeo-nextjs
+
+ pnpm install
+
+ pnpm run dev
+ ```
+
+## Install Auth.js library
+
+Auth.js is a lightweight JavaScript library designed for simplifying authentication workflows in web application. The [Asgardeo provider for Auth.js](https://authjs.dev/reference/core/providers/asgardeo){:target="_blank"} offers all the components and hooks you need to integrate your app with {{product_name}}.To get started, simply add Auth.js library to the project. Make sure to stop the dev server started in the previous step.
+
+=== "npm"
+
+ ``` bash
+ npm install next-auth@beta
+ ```
+
+=== "yarn"
+
+ ``` bash
+ yarn add next-auth@beta
+ ```
+
+=== "pnpm"
+
+ ``` bash
+ pnpm add next-auth@beta
+ ```
+
+Next, generate **`AUTH_SECRET`** environment variable.
+
+=== "npm"
+
+ ``` bash
+ npx auth secret
+
+ ```
+=== "yarn"
+
+ ``` bash
+ yarn dlx auth secret
+ ```
+
+=== "pnpm"
+
+ ``` bash
+ pnpm dlx auth secret
+ ```
+
+Add following entries to the .env or .env.local file, and make sure to replace the placeholders in the following code with the **`client-id`**, **`client-secret`** and **`issuer`** values you copied in **Step-1** during the application registration in the {{product_name}} console.
+
+
+```bash title=".env.local"
+ AUTH_ASGARDEO_ID=""
+ AUTH_ASGARDEO_SECRET=""
+ AUTH_ASGARDEO_ISSUER=""
+
+```
+
+
+
+## Create the `auth.js` configuration File
+
+Create a file called `/src/auth.ts'`.
+
+```bash
+
+touch /src/auth.ts
+
+```
+
+Add {{product_name}} as a provider in the `/src/auth.ts'` file.
+
+```javascript title="auth.ts"
+import NextAuth from "next-auth"
+import Asgardeo from "next-auth/providers/asgardeo"
+
+export const { handlers, signIn, signOut, auth } = NextAuth({
+ providers: [Asgardeo({
+ issuer: process.env.AUTH_ASGARDEO_ISSUER
+ })],
+})
+
+```
+
+Create a Route Handler file in the `src/app/api/auth/[...nextauth]/route.ts` location.
+
+```bash
+mkdir -p src/app/api/auth/\[...nextauth\]
+
+touch mkdir -p src/app/api/auth/\[...nextauth\]/route.ts
+```
+
+!!! Note
+ The directory `src/app/api/auth/[...nextauth]/route.ts` in a Next.js project is used to define a dynamic API route for handling authentication. The `[...nextauth]` is a catch-all route that processes multiple authentication-related requests such as sign-in, sign-out, and session management. The `route.ts` file specifies the logic for these operations, typically by exporting handlers for HTTP methods like GET and POST. This setup centralizes authentication logic, supports OAuth providers like Google or GitHub, and integrates seamlessly into Next.js applications for secure and scalable authentication workflows.
+
+
+Update the `src/app/api/auth/[...nextauth]/route.ts` file with the following code.
+
+```javascript title="route.ts"
+import { handlers } from "@/auth"
+export const { GET, POST } = handlers
+```
+
+Next, create `src/middleware.ts` file with the following code.
+
+```bash
+
+touch mkdir -p src/middleware.ts
+
+```
+
+
+```javascript title="middleware.ts"
+export { auth as middleware } from "@/auth"
+
+```
+
+
+## Add login and logout link to your app
+
+Replace the existing content of the `page.tsx` file with following content to add login and logout features from Auth.JS.
+
+```javascript title="page.tsx"
+import { auth, signIn, signOut } from "@/auth"
+
+export default async function Home() {
+ const session = await auth();
+
+ return (
+
+ {
+ !session ? (
+
+ ) : (
+ <>
+
You are now signed in!
+
+
+ >
+ )
+ }
+
+ );
+}
+```
+
+Visit your app's homepage at [http://localhost:3000](http://localhost:3000).
+
+!!! Important
+
+ You need to create a test user in {{ product_name }} by following this [guide]({{ base_path }}/guides/users/manage-users/#onboard-single-user){:target="_blank"} to tryout login and logout features.
+
+## Display logged in user details
+
+Modified the code as below to see logged in user details.
+
+```javascript title="auth.ts" hl_lines="14-29"
+
+import NextAuth from "next-auth"
+import Asgardeo from "next-auth/providers/asgardeo"
+
+declare module "next-auth" {
+ interface User {
+ username?: string;
+ }
+}
+
+export const { handlers, signIn, signOut, auth } = NextAuth({
+ providers: [Asgardeo({
+ issuer: process.env.AUTH_ASGARDEO_ISSUER
+ })],
+ callbacks: {
+ async jwt({ token, profile }) {
+ if (profile) {
+ token.username = profile.username;
+ }
+
+ return token;
+ },
+ async session({ session, token }) {
+ if (token) {
+ session.user.username = token.username as string;
+ }
+
+ return session;
+ }
+ }
+})
+
+```
+
+Then, update `page.tsx` with the following highlighted line to display the username of logged in user.
+
+```javascript title="page.tsx" hl_lines="4"
+
+...
+<>
+
You are now signed in!
+
hello {session.user?.username}
+
+>
+...
+
+```
+
diff --git a/en/asgardeo/docs/quick-starts/react.md b/en/asgardeo/docs/quick-starts/react.md
index 385d7e5caf..dbb521092d 100644
--- a/en/asgardeo/docs/quick-starts/react.md
+++ b/en/asgardeo/docs/quick-starts/react.md
@@ -9,32 +9,32 @@ what_you_will_learn:
- Display user profile information
prerequisites:
- About 15 minutes
- - Asgardeo account
+ - Asgardeo account
- Install a JS package manager
- A favorite text editor or IDE
source_code: React Vite App Sample
whats_next:
- - Try out Asgardeo complete React guide
- - Try out Asgardeo user onboarding complete guide for React
- - Read Asgardeo security best practices for React app guide
+ - Try out {{ product_name }} complete React guide
+ - Try out {{product_name}} user onboarding complete guide for React
+ - Read security best practices for React app guide
---
-## Configure an Application in Asgardeo
+## Configure an Application in {{ product_name }}
-- Sign into Asgardeo console and navigate to Applications > New Application.
+- Sign into {{ product_name }} console and navigate to Applications > New Application.
- Select Single Page Application and complete the wizard popup by providing a suitable name and an authorized redirect URL
- Name - Asgardeo-React
- Authorized redirect URL - `http://localhost:5173`
-!!! abstract
+!!! Info
The authorized redirect URL determines where Asgardeo should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use`http://localhost:5173`, as the sample app will be accessible at this URL.
!!! note
- Note down the following values : you will need them during the**Step 4**
+ Note down the following values : you will need them during the **Step 4**
- -`client-id`
+ - `client-id`
- `base-url`
- `redirect-url`
@@ -80,19 +80,25 @@ Create (a.k.a scaffold) your new React app using Vite.
## Install @asgardeo/auth-react
-Asgardeo React SDK provides all the components and hooks you need to integrate Asgardeo into your app. To get started, simply add the Asgardeo React SDK to the project.
+Asgardeo React SDK provides all the components and hooks you need to integrate Asgardeo into your app. To get started, simply add the Asgardeo React SDK to the project. Make sure to stop the dev server started in the previous step.
=== "npm"
- ``bash npm install @asgardeo/auth-react ``
+ ``` bash
+ npm install @asgardeo/auth-react
+ ```
=== "yarn"
- ``bash yarn add @asgardeo/auth-react ``
+ ``` bash
+ yarn add @asgardeo/auth-react
+ ```
=== "pnpm"
- ``bash pnpm add @asgardeo/auth-react ``
+ ``` bash
+ pnpm add @asgardeo/auth-react
+ ```
## Add `` to your app
@@ -100,11 +106,11 @@ The `` serves as a context provider for user login in the app. Y
Add the following changes to the `main.jsx` file.
-!!! note
+!!! Important
Replace below placeholders with your registered organization name in Asgardeo and the generated`client-id` from the app you registered in Asgardeo.
- -``
+ - ``
- `https://api.asgardeo.io/t/`
```javascript
@@ -123,11 +129,11 @@ const config = {
}
ReactDOM.createRoot(document.getElementById('root')).render(
-
-
-
-
-,
+
+
+
+
+ ,
);
```
@@ -147,11 +153,11 @@ const { state, signIn, signOut } = useAuthContext();
return (
<>
- {
- state.isAuthenticated
- ?
- :
- }
+ {
+ state.isAuthenticated
+ ?
+ :
+ }
>
)
};
@@ -161,9 +167,9 @@ export default App;
Visit your app's homepage at [http://localhost:5173](http://localhost:5173).
-!!! tip
+!!! Important
- You need to create a test user in Asgardeo by following this guide to tryout login and logout features.
+ You need to create a test user in {{ product_name }} by following this [guide]({{ base_path }}/guides/users/manage-users/#onboard-single-user){:target="_blank"} to tryout login and logout features.
## Display logged in user details
@@ -177,14 +183,14 @@ const App = () => {
return (
<>
- {
- state.isAuthenticated ?
- <>
-
+
+ >
+ :
+ }
>
)
};
diff --git a/en/asgardeo/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml b/en/asgardeo/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml
index e6596fb467..83146be1de 100644
--- a/en/asgardeo/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml
+++ b/en/asgardeo/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml
@@ -24,15 +24,26 @@ paths:
content:
application/json:
schema:
- $ref: '#/components/schemas/SuccessResponse'
- example:
- - actionStatus: SUCCESS
- operations:
- - op: add
- path: /accessToken/claims/-
- value:
- name: customSID
- value: "12345"
+ oneOf:
+ - $ref: '#/components/schemas/SuccessResponse'
+ - $ref: '#/components/schemas/FailedResponse'
+ examples:
+ successExample:
+ summary: Success response
+ value:
+ actionStatus: SUCCESS
+ operations:
+ - op: add
+ path: /accessToken/claims/-
+ value:
+ name: customSID
+ value: "12345"
+ failedExample:
+ summary: Failed response
+ value:
+ actionStatus: FAILED
+ failureReason: invalid_scope
+ failureDescription: "The requested scope is invalid, unknown, or malformed."
"400":
description: Bad Request
content:
@@ -41,7 +52,7 @@ paths:
$ref: '#/components/schemas/ErrorResponse'
example:
- actionStatus: ERROR
- error: invalid_request
+ errorMessage: invalid_request
errorDescription: SID claim is missing
"500":
description: Server Error
@@ -51,7 +62,7 @@ paths:
$ref: '#/components/schemas/ErrorResponse'
example:
- actionStatus: ERROR
- error: server_error
+ errorMessage: server_error
errorDescription: Failed to process the response
components:
schemas:
@@ -282,6 +293,20 @@ components:
items:
$ref: '#/components/schemas/Operations'
description: Defines the success response.
+ FailedResponse:
+ type: object
+ properties:
+ actionStatus:
+ type: string
+ enum:
+ - FAILED
+ description: Indicates the outcome of the request. For a failed operation, this should be set to FAILED.
+ failureReason:
+ type: string
+ description: Provides the reason for failing to issue an access token.
+ failureDescription:
+ type: string
+ description: Offers a detailed explanation of the failure.
ErrorResponse:
type: object
properties:
@@ -290,16 +315,15 @@ components:
enum:
- ERROR
description: Indicates the outcome of the request. For an error operation, this should be set to ERROR.
- error:
+ errorMessage:
type: string
- description: The error code, as specified in OAuth 2.0 error response definitions.
+ description: The cause of the error.
errorDescription:
type: string
description: A detailed description of the error.
description: |
- When the external service responds with an ERROR state, it can return an HTTP status code of 400, 401, or 500, indicating that the expected validations are not met or there is an issue processing the request.
-
- If the defined error response is not received, or if the external service fails to respond, this is identified as an error in executing the action. In such cases, the flow will proceed as if the action was not applied, ensuring that the process continues without disruption.
+ When the external service responds with an ERROR state, it can return an HTTP status code of 400, 401, or 500, indicating either a validation failure or an issue processing the request.
+
RequestBody:
type: object
properties:
diff --git a/en/asgardeo/docs/references/user-management/user-roles.md b/en/asgardeo/docs/references/user-management/user-roles.md
index 0851c781f5..0d3339be79 100644
--- a/en/asgardeo/docs/references/user-management/user-roles.md
+++ b/en/asgardeo/docs/references/user-management/user-roles.md
@@ -1,108 +1,94 @@
# Asgardeo user roles
-Roles consist of the permissions that are required by users to access the Asgardeo resources such as functions available on the Asgardeo Console, REST APIs, etc.
+Roles determine permissions for accessing Asgardeo resources such as functionalities in the Asgardeo Console and underline REST APIs.
-When you assign a role to a user, you are controlling what the user can do in Asgardeo.
+The following roles, available by default, determine the options available for privileged users in the Asgardeo Console.
-By default, Asgardeo has the **Administrator** user role. This role includes all administrative permissions in the organization. An organization can have many users with the administrator role. An administrator is a privileged user who has overall access to the organization.
+!!! note
-
-The following list contains the permissions enabled for an Administrator:
-
-## User management
-- View users
-- Onboard users
-- Update user profiles
-- Delete users
-- Terminate sessions
-- View groups
-- Create groups
-- Update and delete groups
-- View assigned users to groups
-- Assign users to groups
-- Assign users to groups
-- View roles
-- Create roles
-- Update and delete roles
-- Assign users to roles
-- Assign groups to roles
--
-## Application management
-- View apps and app settings
-- Register apps
-- Update and delete apps
-- Update Sign-in methods
-- Update protocol settings
-
-## Connections management
-- View connections and connection settings
-- Create new connection
-- Update and delete connections
-
-## Organization management
-- Create new organizations
-- View all the organizations created
-- As the organization creator, update and delete organizations that you created
-- Switch to the organizations that you created
-- Share applications from the organization (root) to its organizations
-
-## Managing attributes and scopes
-- View attributes
-- Create new attributes
-- Update and delete attributes
-- View scopes
-- Add new attributes to scopes
-- Update and delete scopes
+
+
+
Administrator
+
This role provides all administrative permissions in the organization. An administrator is a privileged user who has overall access to the organization.
+
+
+
Auditor
+
This role provides list and view permissions to Asgardeo resources. With read-only access to all resources in the Asgardeo Console, it is ideal for troubleshooting issues and supporting other users within the organization..
+
+
+
Editor - Applications
+
This role provides permissions for registering and managing applications, ideal for privileged users who can integrate applications with Asgardeo.
+
+
+
Viewer - Applications
+
This role provides permissions for viewing applications and their settings. It is designed for users who need read-only access to applications and their integration settings.
+
+
+
Editor - Users
+
This role provides permissions for managing users and groups within the organization.
+
+
+
Viewer - Users
+
This role provides permissions required for viewing users and groups.
+
+
+
Editor - Connections
+
This role provides permissions for managing connections, ideal for a privileged user who can manage enterprise logins, social logins and MFA options available within the organization.
+
+
-## Managing organization settings
-- View account recovery scenario and settings
-- Configure account recovery scenarios
-- View self registration related settings
-- Configure self registration for users
-- View account security related settings and configurations
-- Configure account security related settings
+The following tables elaborate all the permissions enabled for the default roles available for the Asgardeo Console.
-
diff --git a/en/asgardeo/features.json b/en/asgardeo/features.json
new file mode 100644
index 0000000000..4d55f436af
--- /dev/null
+++ b/en/asgardeo/features.json
@@ -0,0 +1,19 @@
+{
+ "asgardeo_logs": {
+ "enabled": true,
+ "page": [
+ "guides/asgardeo-logs/index.md",
+ "guides/asgardeo-logs/diagnostic-logs.md",
+ "guides/asgardeo-logs/audit-logs.md"
+ ]
+ },
+
+ "applications": {
+ "enabled": true,
+ "page": [
+ "guides/applications/register-single-page-app.md",
+ "guides/applications/register-oidc-web-app.md",
+ "guides/applications/register-saml-web-app.md"
+ ]
+ }
+}
diff --git a/en/asgardeo/hooks.py b/en/asgardeo/hooks.py
new file mode 100644
index 0000000000..6cc462c786
--- /dev/null
+++ b/en/asgardeo/hooks.py
@@ -0,0 +1,53 @@
+import os
+import json
+from mkdocs.structure.nav import Section, Page, Link
+
+def parse_json(file_path):
+ features_to_remove = {"feature": {}, "page": []}
+ with open(file_path, 'r') as json_file:
+ parse_data = json.load(json_file)
+ for feature, details in parse_data.items():
+ enabled = details['enabled']
+ page = details['page']
+ features_to_remove['feature'][feature] = enabled
+
+ if not enabled:
+ features_to_remove['page'].extend(page)
+ json_file.close()
+ return features_to_remove
+
+files_to_remove = parse_json(os.path.join(os.getcwd(), 'features.json'))
+
+def on_files(files, config):
+ for file in list(files):
+ if file.src_uri in files_to_remove['page']:
+ files.remove(file)
+ return files
+
+def remove_nav_item(nav_items):
+ filtered_items = []
+
+ for item in nav_items:
+ if isinstance(item, dict):
+ if any(page in item.values() for page in files_to_remove['page']):
+ continue
+ for key, value in item.items():
+ if isinstance(value, list):
+ value = remove_nav_item(value)
+ item[key] = value
+ item = {k: v for k, v in item.items() if not (isinstance(v, list) and not v)}
+ if item:
+ filtered_items.append(item)
+ elif isinstance(item, list):
+ if item:
+ filtered_items.append(item)
+
+ return filtered_items
+
+def on_config(config):
+
+ for feature, enabled in files_to_remove['feature'].items():
+ config[feature] = enabled
+
+ config['nav'] = remove_nav_item(config['nav'])
+ return config
diff --git a/en/asgardeo/mkdocs.yml b/en/asgardeo/mkdocs.yml
index 3a61b4f7a0..845eda7e4a 100644
--- a/en/asgardeo/mkdocs.yml
+++ b/en/asgardeo/mkdocs.yml
@@ -33,6 +33,7 @@ extra:
product: asgardeo
product_name: *site_name
nav_list:
+ - Home
- Get Started
- Guides
- Tutorials
@@ -93,6 +94,9 @@ watch:
- ../theme/material
- ../base.yml
+hooks:
+ - hooks.py
+
plugins:
- search
- markdownextradata: {}
@@ -123,6 +127,19 @@ plugins:
'references/application-logs.md' : 'guides/asgardeo-logs.md'
'apis/oauth-dcr.md' : 'apis/dynamic-client-registration-rest-api.md'
'/guides/authorization/impersonation/user-impersonation/' : '/guides/authorization/user-impersonation/'
+ 'guides/branding/localization-in-asgardeo.md': 'guides/branding/localization.md'
+
+exclude_docs: |
+ /get-started/hello-world.md
+
+not_in_nav: |
+ /page-not-found.md
+ /get-started/explore-asgardeo.md
+ /get-started/start-integrating-apps.md
+ /get-started/try-samples/index.md
+ /get-started/try-your-own-app/index.md
+ /get-started/try-your-own-app/angular.md
+ /get-started/hello-world.md
# Navigation
nav:
@@ -271,9 +288,9 @@ nav:
- Manage roles: guides/users/manage-roles.md
- Manage active sessions: guides/users/manage-sessions.md
- Migrate users to Asgardeo:
- - Migrate users to Asgardeo: guides/users/migrate-users-to-asgardeo/index.md
- - Migrate user accounts: guides/users/migrate-users-to-asgardeo/migrate-users.md
- - Migrate user passwords: guides/users/migrate-users-to-asgardeo/migrate-passwords.md
+ - Migrate users to Asgardeo: guides/users/migrate-users/index.md
+ - Migrate user accounts: guides/users/migrate-users/migrate-users.md
+ - Migrate user passwords: guides/users/migrate-users/migrate-passwords.md
- Manage attributes and mappings:
- Manage attributes and mappings: guides/users/attributes/index.md
- User attributes: guides/users/attributes/manage-attributes.md
@@ -333,7 +350,7 @@ nav:
- Branding AI: guides/branding/ai-branding.md
- Configure custom domains: guides/branding/configure-custom-domains.md
- Customize email templates: guides/branding/customize-email-templates.md
- - Localization in Asgardeo: guides/branding/localization-in-asgardeo.md
+ - Localization in Asgardeo: guides/branding/localization.md
- Extend with actions:
- Understanding actions: guides/customize/actions/understanding-actions.md
- Setting up actions: guides/customize/actions/setting-up-actions.md
@@ -409,8 +426,8 @@ nav:
- Session extension API: apis/extend-sessions.md
- User store management API: apis/user-store.md
- Validation API: apis/validation.md
- - Orgnization APIs:
- - Orgnization APIs: apis/organization-apis/index.md
+ - Organization APIs:
+ - Organization APIs: apis/organization-apis/index.md
- Get access for organization APIs: apis/organization-apis/authentication.md
- Application management API: apis/organization-apis/org-application-management.md
- Authenticators API: apis/organization-apis/org-authenticators.md
@@ -474,6 +491,29 @@ nav:
- Client-request: references/token-binding/client-request.md
- Financial-grade API: references/financial-grade-api.md
- App-native authentication: references/app-native-authentication.md
+ - React Guide:
+ - Introduction: complete-guides/react/introduction.md
+ - Prerequisite: complete-guides/react/prerequisite.md
+ - Configure an application: complete-guides/react/register-an-application.md
+ - Create a React app: complete-guides/react/create-a-react-app.md
+ - Configure Asgardeo SDK: complete-guides/react/install-asgardeo-sdk.md
+ - Add login and logout: complete-guides/react/add-login-and-logout.md
+ - Display user details: complete-guides/react/display-logged-in-user-details.md
+ - Securing Routes: complete-guides/react/securing-routes-within-the-app.md
+ - Accessing protected API : complete-guides/react/accessing-protected-api.md
+ - Manage tokens in React : complete-guides/react/manage-tokens-in-React-apps.md
+ - Next Steps: complete-guides/react/next-steps.md
+ - Node.js Guide:
+ - Introduction: complete-guides/nodejs/introduction.md
+ - Prerequisite: complete-guides/nodejs/prerequisite.md
+ - Configure an application: complete-guides/nodejs/register-an-application.md
+ - Create a Node.js app: complete-guides/nodejs/create-a-nodejs-app.md
+ - Configure Passport Asgardeo: complete-guides/nodejs/install-passport-asgardeo.md
+ - Add login and logout: complete-guides/nodejs/add-login-and-logout.md
+ - Display user details: complete-guides/nodejs/display-logged-in-user-details.md
+ - Securing Routes: complete-guides/nodejs/securing-routes-within-the-app.md
+ - Accessing protected API : complete-guides/nodejs/accessing-protected-api.md
+ - Next Steps: complete-guides/nodejs/next-steps.md
not_in_nav: |
/page-not-found.md
diff --git a/en/asgardeo/requirements.txt b/en/asgardeo/requirements.txt
index 287caf7b03..a3849ac591 100644
--- a/en/asgardeo/requirements.txt
+++ b/en/asgardeo/requirements.txt
@@ -1,4 +1,4 @@
-mkdocs==1.5.3
+mkdocs==1.6.1
Pygments==2.14.0
pymdown-extensions==10.3.1
mkdocs-minify-plugin==0.6.2
@@ -6,10 +6,12 @@ mkdocs-markdownextradata-plugin==0.2.5
mkdocs-redirects==1.2.0
pathlib==1.0.1
mkdocs-material==9.1.2
-markdown==3.2.1
+markdown==3.3.6
mkdocs-redirects==1.2.0
mkdocs-exclude==1.0.2
markdown-include==0.8.1
jinja2==3.1.2
mkdocs-glightbox==0.3.4
-mkdocs-include-markdown-plugin==6.0.0
\ No newline at end of file
+mkdocs-include-markdown-plugin==6.0.0
+mkdocs-macros-plugin==1.2.0
+mkdocs-exclude==1.0.2
diff --git a/en/base.yml b/en/base.yml
index 6576b8d5e4..af3eabfd89 100644
--- a/en/base.yml
+++ b/en/base.yml
@@ -29,6 +29,8 @@ theme:
- navigation.indexes
- navigation.path
- navigation.top
+ - navigation.footer
+ - navigation.instant.progress
- content.code.copy
- content.action.edit
- content.action.view
@@ -104,13 +106,13 @@ extra:
integrations:
- name: Auth React SDK
icon: assets/img/logo/react-logo.svg
- description: An SDK to integrate {{ config.extra.product_name }} into React applications
+ description: An SDK to integrate {{ product_name }} into React applications
documentation_link: get-started/try-your-own-app/react/
download_link: https://github.com/asgardeo/asgardeo-auth-react-sdk/releases/latest/download/asgardeo-react-app.zip
source_link: https://github.com/asgardeo/asgardeo-auth-react-sdk
- name: Auth SPA SDK
icon: assets/img/logo/javascript-logo.svg
- description: An SDK to integrate {{ config.extra.product_name }} into single page applications
+ description: An SDK to integrate {{ product_name }} into single page applications
documentation_link: get-started/try-your-own-app/javascript/
download_link: https://github.com/asgardeo/asgardeo-auth-spa-sdk/releases/latest/download/asgardeo-html-js-app.zip
source_link: https://github.com/asgardeo/asgardeo-auth-spa-sdk
@@ -126,7 +128,7 @@ extra:
- name: Auth Node SDK
icon: assets/img/logo/expressjs-logo.svg
dark_icon: assets/img/logo/expressjs-logo-dark.svg
- description: An SDK to integrate {{ config.extra.product_name }} into JS/TS-based frameworks such as ExpressJS
+ description: An SDK to integrate {{ product_name }} into JS/TS-based frameworks such as ExpressJS
source_link: https://github.com/asgardeo/asgardeo-auth-node-sdk
- name: Tomcat OIDC Agent
icon: assets/img/logo/java-logo.svg
@@ -159,7 +161,7 @@ extra:
source_link: https://github.com/openid/AppAuth-iOS
- name: Android Mobile UI SDK
icon: assets/img/logo/android-logo.svg
- description: A client SDK to integrate {{ config.extra.product_name }} into Android mobile applications using "app-native authentication"
+ description: A client SDK to integrate {{ product_name }} into Android mobile applications using "app-native authentication"
documentation_link: https://asgardeo.github.io/mobile-ui-sdks/android/introduction.html
source_link: https://github.com/asgardeo/mobile-ui-sdks/tree/main/android
redoc_theme: '{
diff --git a/en/identity-server/6.0.0/docs/references/about-this-release.md b/en/identity-server/6.0.0/docs/references/about-this-release.md
index 622929c597..fe92ccb952 100644
--- a/en/identity-server/6.0.0/docs/references/about-this-release.md
+++ b/en/identity-server/6.0.0/docs/references/about-this-release.md
@@ -133,7 +133,8 @@ The following features are removed from WSO2 Identity Server 6.0.0.
- H2 Console
- Embedded LDAP user store
- Carbon metrics
-- Yahoo authenticator
+- Yahoo authenticator
+- Legacy OpenID authentication
- reCAPTCHA v2 "I'm not a robot" Checkbox
- Hazelcast DNS based pod discovery in Kubernetes membership scheme
diff --git a/en/identity-server/6.1.0/docs/apis/restapis/application.yaml b/en/identity-server/6.1.0/docs/apis/restapis/application.yaml
index adc620d5d6..ab0008eb7f 100644
--- a/en/identity-server/6.1.0/docs/apis/restapis/application.yaml
+++ b/en/identity-server/6.1.0/docs/apis/restapis/application.yaml
@@ -1,8 +1,7 @@
openapi: 3.0.0
info:
description: >
- This document specifies an **Application Management RESTful API** for **WSO2
- Identity Server**.
+ This document specifies an **Application Management RESTful API** for **WSO2 Identity Server**.
version: "v1"
title: WSO2 Identity Server - Application Management Rest API
termsOfService: 'http://swagger.io/terms/'
@@ -13,7 +12,6 @@ info:
license:
name: Apache 2.0
url: 'http://www.apache.org/licenses/LICENSE-2.0.html'
-
security:
- OAuth2: []
- BasicAuth: []
@@ -24,7 +22,7 @@ paths:
- Applications
operationId: getAllApplications
summary: |
- List applications
+ List applications.
description: |
This API provides the capability to retrieve the list of applications. Permission required:
@@ -77,15 +75,11 @@ paths:
tags:
- Applications
summary: |
- Add application
+ Add application.
operationId: createApplication
description: >
- This API provides the capability to store the application information
- that is provided by users.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/create
- Scope required:
- * internal_application_mgt_create
+ This API provides the capability to store the application information that is provided by users.
+ Scope(Permission) required: `internal_application_mgt_create`
parameters:
- in: query
name: template
@@ -142,15 +136,12 @@ paths:
tags:
- Applications
summary: |
- Create application from an exported XML file
+ Create application from an exported XML, YAML, or JSON file.
operationId: importApplication
description: >
- This API provides the capability to store the application information,
- provided as a file.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/create
- Scope required:
- * internal_application_mgt_create
+ This API provides the capability to create an application based on the
+ information provided in an XML, YAML, or JSON file.
+ Scope(Permission) required: `internal_application_mgt_create`
requestBody:
content:
multipart/form-data:
@@ -191,14 +182,12 @@ paths:
tags:
- Applications
summary: |
- Update application from an exported XML file
+ Update application from an exported XML, YAML, or JSON file.
operationId: importApplicationForUpdate
description: >
- This API provides the capability to update an application from information that has been exported as an XML file.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to update an application based on the
+ information provided in an XML, YAML, or JSON file.
+ Scope(Permission) required: `internal_application_mgt_update`
requestBody:
content:
multipart/form-data:
@@ -241,20 +230,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
- '/applications/{applicationId}':
+ /applications/{applicationId}:
get:
tags:
- Applications
summary: |
- Retrieve application by ID
+ Retrieve application by ID.
operationId: getApplication
description: >
- This API provides the capability to retrieve the application information
- by ID.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve the application information by ID.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- name: applicationId
in: path
@@ -300,19 +285,15 @@ paths:
application/xml:
schema:
$ref: '#/components/schemas/Error'
-
patch:
tags:
- Applications
summary: |
- Partially update application by ID
+ Partially update application by ID.
operationId: patchApplication
description: |
- This API provides the capability to partially update an application by ID.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to partially update an application by ID.
+ Scope(Permission) required: `internal_application_mgt_update`
parameters:
- name: applicationId
in: path
@@ -356,14 +337,11 @@ paths:
tags:
- Applications
summary: |
- Delete application by ID
+ Delete application by ID.
operationId: deleteApplication
description: |
This API provides the capability to delete an application by ID.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/delete
- Scope required:
- * internal_application_mgt_delete
+ Scope(Permission) required: `internal_application_mgt_delete`
parameters:
- name: applicationId
in: path
@@ -402,13 +380,10 @@ paths:
- Applications
operationId: exportApplication
summary: |
- Export application as an XML file
+ Export application as an XML file.
description: |
- This API provides the capability to retrieve the application as an XML file.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve the application as an XML file.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- name: applicationId
in: path
@@ -452,13 +427,10 @@ paths:
- Applications
operationId: changeApplicationOwner
summary: |
- Change application owner
+ Change application owner.
description: |
- This API provides the capability to change the application owner.
- Permission required:
- * /permission/admin
- Scope required:
- * SYSTEM
+ This API provides the capability to change the application owner.
+ Scope(Permission) required: `internal_organization_admin`
parameters:
- name: applicationId
in: path
@@ -501,14 +473,11 @@ paths:
tags:
- Authenticators
summary: |
- Get configured authenticators
+ Get configured authenticators.
operationId: getConfiguredAuthenticators
description: |
- This API provides the capability to retrieve the configured authenticators.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve the configured authenticators.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- name: applicationId
in: path
@@ -552,15 +521,11 @@ paths:
tags:
- Resident Application
summary: |
- Get Resident application
+ Get resident application.
operationId: getResidentApplication
description: |
- This API provides the capability to retrieve the resident application information.
-
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve the resident application information.
+ Scope(Permission) required: `internal_application_mgt_view`
responses:
'200':
description: OK
@@ -594,14 +559,11 @@ paths:
tags:
- Resident Application
summary: |
- Update Resident Application
+ Update resident application.
operationId: updateResidentApplication
description: >
- This API provides the capability to update the Resident Application Configuration.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to update the resident application configuration.
+ Scope(Permission) required: `internal_application_mgt_update`
responses:
'200':
description: Successful
@@ -651,20 +613,16 @@ paths:
This represents the provisioning configuration of the resident
application.
required: true
- '/applications/{applicationId}/inbound-protocols/':
+ /applications/{applicationId}/inbound-protocols/:
get:
tags:
- Inbound Protocols
summary: |
- Retrieve inbound protocol configurations of the application
+ Retrieve inbound protocol configurations.
operationId: getInboundAuthenticationConfigurations
description: >
- This API provides the capability to retrieve authentication protocol
- configurations of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve authentication protocol configurations of an application.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- name: applicationId
in: path
@@ -701,20 +659,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
- '/applications/{applicationId}/inbound-protocols/saml':
+ /applications/{applicationId}/inbound-protocols/saml:
get:
tags:
- Inbound Protocols - SAML
summary: |
- Retrieve SAML2 authentication protocol parameters of application
+ Retrieve SAML2 authentication protocol parameters.
operationId: getInboundSAMLConfiguration
description: >
- This API provides the capability to retrieve SAML2 authentication
- protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve SAML2 authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- name: applicationId
in: path
@@ -751,20 +705,15 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
put:
tags:
- Inbound Protocols - SAML
summary: |
- Update SAML2 authentication protocol parameters of application
+ Update SAML2 authentication protocol parameters.
operationId: updateInboundSAMLConfiguration
description: >
- This API provides the capability to store SAML2 authentication protocol
- parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to store SAML2 authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_update`
- There are three methods to create/update SAML2 authentication protocol configuration.
1. Metadata File (by sending the Base64 encoded content of the metadata file.)
@@ -826,15 +775,11 @@ paths:
tags:
- Inbound Protocols - SAML
summary: |
- Delete SAML2 authentication protocol parameters of application
+ Delete SAML2 authentication protocol parameters.
operationId: deleteInboundSAMLConfiguration
description: >
- This API provides the capability to delete SAML2 authentication protocol
- parameters of an application.
- Permissi on required:
- * /permission/admin/manage/identity/applicationmgt/delete
- Scope required:
- * internal_application_mgt_delete
+ This API provides the capability to delete SAML2 authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_delete`
parameters:
- name: applicationId
in: path
@@ -867,21 +812,15 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
-
- '/applications/{applicationId}/inbound-protocols/oidc':
+ /applications/{applicationId}/inbound-protocols/oidc:
get:
tags:
- Inbound Protocols - OAuth / OIDC
summary: |
- Retrieve OIDC authentication protocol parameters of application
+ Retrieve OIDC authentication protocol parameters.
description: >
- This API provides the capability to retrieve OIDC authentication
- protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve OIDC authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getInboundOAuthConfiguration
parameters:
- name: applicationId
@@ -923,14 +862,10 @@ paths:
tags:
- Inbound Protocols - OAuth / OIDC
summary: |
- Update OIDC authentication protocol parameters of application
+ Update OIDC authentication protocol parameters.
description: >
- This API provides the capability to store OIDC authentication protocol
- parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to store OIDC authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_update`
operationId: updateInboundOAuthConfiguration
parameters:
- name: applicationId
@@ -990,14 +925,10 @@ paths:
tags:
- Inbound Protocols - OAuth / OIDC
summary: |
- Delete OIDC authentication protocol parameters of application
+ Delete OIDC authentication protocol parameters.
description: >
- This API provides the capability to delete OIDC authentication protocol
- parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/delete
- Scope required:
- * internal_application_mgt_delete
+ This API provides the capability to delete OIDC authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_delete`
operationId: deleteInboundOAuthConfiguration
parameters:
- name: applicationId
@@ -1031,20 +962,15 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
-
- '/applications/{applicationId}/inbound-protocols/oidc/regenerate-secret':
+ /applications/{applicationId}/inbound-protocols/oidc/regenerate-secret:
post:
tags:
- Inbound Protocols - OAuth / OIDC
summary: |
- Regenerate the OAuth2/OIDC client secret of application
+ Regenerate the OAuth2/OIDC client secret.
description: |
This API regenerates the OAuth2/OIDC client secret.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/create
- Scope required:
- * internal_application_mgt_create
+ Scope(Permission) required: `internal_application_mgt_create`
operationId: regenerateOAuthClientSecret
parameters:
- name: applicationId
@@ -1082,19 +1008,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/{applicationId}/inbound-protocols/oidc/revoke':
+ /applications/{applicationId}/inbound-protocols/oidc/revoke:
post:
tags:
- Inbound Protocols - OAuth / OIDC
summary: |
- Revoke the OAuth2/OIDC client of application
+ Revoke the OAuth2/OIDC client of application.
description: |
- This API revokes the OAuth2/OIDC client secret. To re-activate the client, the client secret needs to be regenerated.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/create
- Scope required:
- * internal_application_mgt_create
+ This API revokes the OAuth2/OIDC client secret.
+ To re-activate the client, the client secret needs to be regenerated.
+ Scope(Permission) required: `internal_application_mgt_create`
operationId: revokeOAuthClient
parameters:
- name: applicationId
@@ -1128,20 +1051,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/{applicationId}/inbound-protocols/passive-sts':
+ /applications/{applicationId}/inbound-protocols/passive-sts:
get:
tags:
- Inbound Protocols - Passive STS
summary: >
- Retrieve Passive STS authentication protocol parameters of application
+ Retrieve Passive STS authentication protocol parameters.
description: >
This API provides the capability to retrieve Passive STS authentication
protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getPassiveStsConfiguration
parameters:
- name: applicationId
@@ -1179,19 +1098,14 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
put:
tags:
- Inbound Protocols - Passive STS
summary: |
- Update Passive STS authentication protocol parameters of application
+ Update Passive STS authentication protocol parameters.
description: >
- This API provides the capability to store passive STS authentication
- protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to store passive STS authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_update`
operationId: updatePassiveStsConfiguration
parameters:
- name: applicationId
@@ -1240,7 +1154,6 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
requestBody:
content:
application/json:
@@ -1254,14 +1167,11 @@ paths:
tags:
- Inbound Protocols - Passive STS
summary: |
- Delete Passive STS authentication protocol parameters of application
+ Delete Passive STS authentication protocol parameters.
description: >
This API provides the capability to delete Passive STS authentication
protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/delete
- Scope required:
- * internal_application_mgt_delete
+ Scope(Permission) required: `internal_application_mgt_delete`
operationId: deletePassiveStsConfiguration
parameters:
- name: applicationId
@@ -1295,20 +1205,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/{applicationId}/inbound-protocols/ws-trust':
+ /applications/{applicationId}/inbound-protocols/ws-trust:
get:
tags:
- Inbound Protocols - WS Trust
summary: |
- Retrieve WS Trust authentication protocol parameters of application
+ Retrieve WS Trust authentication protocol parameters.
description: >
This API provides the capability to retrieve Passive STS authentication
protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getWSTrustConfiguration
parameters:
- name: applicationId
@@ -1346,19 +1252,14 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
put:
tags:
- Inbound Protocols - WS Trust
summary: |
- Update WS Trust authentication protocol parameters of application
+ Update WS Trust authentication protocol parameters.
description: >
- This API provides the capability to store WS Trust authentication
- protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to store WS Trust authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_update`
operationId: updateWSTrustConfiguration
parameters:
- name: applicationId
@@ -1407,7 +1308,6 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
requestBody:
content:
application/json:
@@ -1421,14 +1321,10 @@ paths:
tags:
- Inbound Protocols - WS Trust
summary: |
- Delete WS Trust authentication protocol parameters of application
+ Delete WS Trust authentication protocol parameters.
description: >
- This API provides the capability to delete WS Trust authentication
- protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/delete
- Scope required:
- * internal_application_mgt_delete
+ This API provides the capability to delete WS Trust authentication protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_delete`
operationId: deleteWSTrustConfiguration
parameters:
- name: applicationId
@@ -1462,20 +1358,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/{applicationId}/inbound-protocols/{inboundProtocolId}':
+ /applications/{applicationId}/inbound-protocols/{inboundProtocolId}:
get:
tags:
- Inbound Protocols - Custom
summary: >
- Retrieve custom Inbound authentication protocol parameters of application.
+ Retrieve custom inbound authentication protocol parameters.
description: >
This API provides the capability to retrieve custom inbound
authentication protocol parameters of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getCustomInboundConfiguration
parameters:
- name: applicationId
@@ -1523,14 +1415,11 @@ paths:
tags:
- Inbound Protocols - Custom
summary: |
- Update the custom inbound authentication protocol parameters of application
+ Update the custom inbound authentication protocol parameters.
description: >
- This API provides the capability to store custom inbound authentication protocol parameters of an application.
-
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/update
- Scope required:
- * internal_application_mgt_update
+ This API provides the capability to store custom inbound authentication
+ protocol parameters of an application.
+ Scope(Permission) required: `internal_application_mgt_update`
operationId: updateCustomInboundConfiguration
parameters:
- name: applicationId
@@ -1598,13 +1487,10 @@ paths:
tags:
- Inbound Protocols - Custom
summary: >
- Delete custom inbound authentication protocol parameters of application
+ Delete custom inbound authentication protocol parameters.
description: >
This API provides the capability to delete custom inbound authentication protocol of an application.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/delete
- Scope required:
- * internal_application_mgt_delete
+ Scope(Permission) required: `internal_application_mgt_delete`
operationId: deleteCustomInboundConfiguration
parameters:
- name: applicationId
@@ -1644,21 +1530,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/meta/inbound-protocols':
+ /applications/meta/inbound-protocols:
get:
tags:
- Application Metadata
summary: |
- Retrieve the list of inbound authentication protocols available
+ Retrieve the list of inbound authentication protocols available.
description: >
This API provides the capability to retrieve the list of inbound authentication protocols available.
- If the query parameter 'customOnly' is set to true, only custom inbound protocols will be listed.
-
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ If the query parameter 'customOnly' is set to true, only custom inbound protocols will be listed.
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getInboundProtocols
parameters:
- $ref: '#/components/parameters/inboundProtocolsCustomOnly'
@@ -1690,19 +1571,15 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/meta/inbound-protocols/saml':
+ /applications/meta/inbound-protocols/saml:
get:
tags:
- Application Metadata
summary: |
- Retrieve all the metadata related to the auth protocol SAML
+ Retrieve all the metadata related to the auth protocol SAML.
description: >
This API provides the capability to retrieve all the metadata related to the auth protocol SAML.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getSAMLMetadata
responses:
'200':
@@ -1735,19 +1612,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/meta/inbound-protocols/oidc':
+ /applications/meta/inbound-protocols/oidc:
get:
tags:
- Application Metadata
summary: |
- Retrieve all the metadata related to the authentication protocol OAuth / OIDC
+ Retrieve all the metadata related to the authentication protocol OAuth / OIDC.
description: >
- This API provides the capability to retrieve all the metadata related to the authentication protocol OAuth / OIDC.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ This API provides the capability to retrieve all the metadata related
+ to the authentication protocol OAuth / OIDC.
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getOIDCMetadata
responses:
'200':
@@ -1772,19 +1646,15 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/meta/inbound-protocols/ws-trust':
+ /applications/meta/inbound-protocols/ws-trust:
get:
tags:
- Application Metadata
summary: |
- Retrieve all the metadata related to the auth protocol WS Trust
+ Retrieve all the metadata related to the auth protocol WS Trust.
description: >
This API provides the capability to retrieve all the metadata related to the auth protocol WS_Trust.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getWSTrustMetadata
responses:
'200':
@@ -1809,20 +1679,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/meta/inbound-protocols/{inboundProtocolId}':
+ /applications/meta/inbound-protocols/{inboundProtocolId}:
get:
tags:
- Application Metadata
summary: |
- Retrieve all the metadata related to the custom auth protocol identified by the inboundProtocolId
+ Retrieve all the metadata related to the custom auth protocol identified by the inboundProtocolId.
description: >
This API provides the capability to retrieve all the metadata related to the custom auth protocol
- identified by the inboundProtocolId. The URL encoded inbound protocol name is used as inboundProtocolId.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ identified by the inboundProtocolId. The URL encoded inbound protocol name is used as inboundProtocolId.
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getCustomProtocolMetadata
parameters:
- name: inboundProtocolId
@@ -1854,19 +1720,15 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
- '/applications/meta/adaptive-auth-templates':
+ /applications/meta/adaptive-auth-templates:
get:
tags:
- Application Metadata
summary: |
- Retrieve the sample adaptive authentication templates.
+ Retrieve adaptive authentication sample templates.
description: >
This API provides the capability to retrieve the sample adaptive authentication templates.
- Permission required:
- * /permission/admin/manage/identity/applicationmgt/view
- Scope required:
- * internal_application_mgt_view
+ Scope(Permission) required: `internal_application_mgt_view`
operationId: getAdaptiveAuthTemplates
responses:
'200':
@@ -1891,16 +1753,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
/applications/templates:
get:
tags:
- Application Templates
operationId: getAllApplicationTemplates
summary: |
- List Application Templates
+ List application templates.
description: |
- This API provides the capability to retrieve the list of templates available.
+ This API provides the capability to retrieve the list of templates available.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- $ref: '#/components/parameters/limitWithoutDefaultQueryParam'
- $ref: '#/components/parameters/offsetWithoutDefaultQueryParam'
@@ -1944,10 +1806,11 @@ paths:
tags:
- Application Templates
summary: |
- Add application template
+ Add application template.
operationId: createApplicationTemplate
description: >
- This API provides the capability to store the application template provided by users.
+ This API provides the capability to store the application template provided by users.
+ Scope(Permission) required: `internal_application_mgt_create`
requestBody:
content:
application/json:
@@ -1992,16 +1855,16 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
/applications/templates/{template-id}:
get:
tags:
- Application Templates
summary: |
- Retrieve application template by ID
+ Retrieve application template by ID.
operationId: getApplicationTemplate
description: >
- This API provides the capability to retrieve the application template from the template id.
+ This API provides the capability to retrieve the application template from the template id.
+ Scope(Permission) required: `internal_application_mgt_view`
parameters:
- $ref: '#/components/parameters/templateIdPathParam'
responses:
@@ -2042,7 +1905,6 @@ paths:
application/xml:
schema:
$ref: '#/components/schemas/Error'
-
put:
tags:
- Application Templates
@@ -2050,7 +1912,8 @@ paths:
Update the application template by the template ID.
operationId: updateApplicationTemplate
description: |
- This API provides the capability to update an application template by the template ID.
+ This API provides the capability to update an application template by the template ID.
+ Scope(Permission) required: `internal_application_mgt_update`
parameters:
- $ref: '#/components/parameters/templateIdPathParam'
requestBody:
@@ -2098,7 +1961,8 @@ paths:
Delete application template by template ID.
operationId: deleteApplicationTemplate
description: |
- This API provides the capability to delete an application template by template ID.
+ This API provides the capability to delete an application template by template ID.
+ Scope(Permission) required: `internal_application_mgt_delete`
parameters:
- $ref: '#/components/parameters/templateIdPathParam'
responses:
@@ -2129,7 +1993,6 @@ paths:
application/json:
schema:
$ref: '#/components/schemas/Error'
-
components:
parameters:
limitQueryParam:
@@ -2210,9 +2073,10 @@ components:
required: false
description: |
Specifies the required parameters in the response.
- Only 'advancedConfigurations', 'templateId', 'clientId', and 'issuer' attributes are currently supported.
+ Only 'advancedConfigurations', 'templateId', 'clientId', 'issuer', and 'associatedRoles.allowedAudience'
+ attributes are currently supported.
- /applications?attributes=advancedConfigurations,templateId,clientId,issuer
+ /applications?attributes=advancedConfigurations,templateId,clientId,issuer,associatedRoles.allowedAudience
schema:
type: string
exportSecretsQueryParam:
@@ -2251,7 +2115,7 @@ components:
flows:
authorizationCode:
authorizationUrl: 'https://localhost:9443/oauth2/authorize'
- tokenUrl: 'http://localhost:9763/oauth2/token'
+ tokenUrl: 'http://localhost:9443/oauth2/token'
scopes: {}
schemas:
Link:
@@ -2263,7 +2127,6 @@ components:
rel:
type: string
example: "next"
-
ApplicationListResponse:
type: object
properties:
@@ -2287,7 +2150,6 @@ components:
type: array
items:
$ref: '#/components/schemas/Link'
-
ApplicationListItem:
type: object
properties:
@@ -2326,7 +2188,6 @@ components:
templateId:
type: string
example: "980b8tester24c64a8a09a0d80abf8c337bd2555"
-
ApplicationModel:
type: object
required:
@@ -2348,6 +2209,9 @@ components:
accessUrl:
type: string
example: 'https://example.com/login'
+ logoutReturnUrl:
+ type: string
+ example: 'https://example.com/app/logout'
templateId:
type: string
example: "980b8tester24c64a8a09a0d80abf8c337bd2555"
@@ -2366,7 +2230,6 @@ components:
$ref: '#/components/schemas/AdvancedApplicationConfiguration'
provisioningConfigurations:
$ref: '#/components/schemas/ProvisioningConfiguration'
-
ApplicationResponseModel:
type: object
required:
@@ -2388,6 +2251,9 @@ components:
accessUrl:
type: string
example: 'https://example.com/login'
+ logoutReturnUrl:
+ type: string
+ example: 'https://example.com/app/logout'
clientId:
type: string
example: 'SmrrDNXRYf1lMmDlnleeHTuXx_Ea'
@@ -2417,7 +2283,6 @@ components:
- READ
- WRITE
default: READ
-
ApplicationPatchModel:
type: object
properties:
@@ -2433,6 +2298,9 @@ components:
accessUrl:
type: string
example: 'https://example.com/login'
+ logoutReturnUrl:
+ type: string
+ example: 'https://example.com/app/logout'
templateId:
type: string
example: "adwefi2429asdfdf94444rraf44"
@@ -2444,13 +2312,11 @@ components:
$ref: '#/components/schemas/AdvancedApplicationConfiguration'
provisioningConfigurations:
$ref: '#/components/schemas/ProvisioningConfiguration'
-
ResidentApplication:
type: object
properties:
provisioningConfigurations:
$ref: '#/components/schemas/ProvisioningConfiguration'
-
ProvisioningConfiguration:
type: object
properties:
@@ -2472,7 +2338,6 @@ components:
description: >-
This property becomes only applicable if the proxy-mode config is
set to false
-
OutboundProvisioningConfiguration:
type: object
properties:
@@ -2505,15 +2370,15 @@ components:
type: array
items:
$ref: '#/components/schemas/ConfiguredAuthenticator'
- ConfiguredAuthenticator:
- type: object
- properties:
- name:
- type: string
- example: sampleIdP
- type:
- type: string
- example: SampleAuthenticator
+ ConfiguredAuthenticator:
+ type: object
+ properties:
+ name:
+ type: string
+ example: sampleIdP
+ type:
+ type: string
+ example: SampleAuthenticator
AdvancedApplicationConfiguration:
type: object
properties:
@@ -2543,6 +2408,10 @@ components:
type: boolean
description: Decides whether authorization policies needs to be engaged during authentication flows.
example: true
+ fragment:
+ type: boolean
+ description: Decides whether application is a fragment application.
+ example: false
additionalSpProperties:
$ref: '#/components/schemas/AdditionalProperties'
AdditionalProperties:
@@ -2592,12 +2461,10 @@ components:
type: array
items:
$ref: '#/components/schemas/CustomInboundProtocolConfiguration'
-
InboundProtocolsListResponse:
type: array
items:
$ref: '#/components/schemas/InboundProtocolListItem'
-
InboundProtocolListItem:
type: object
required:
@@ -2613,8 +2480,7 @@ components:
example: "SAML2 Inbound"
self:
type: string
- example: "/t/carbon.super/api/server/v1/applications/29048810-1447-4ea0-a348-30d15ab65fa3/inbound-protocols/saml"
-
+ example: "/api/server/v1/applications/29048810-1447-4ea0-a348-30d15ab65fa3/inbound-protocols/saml"
ClaimConfiguration:
type: object
properties:
@@ -2716,7 +2582,6 @@ components:
type: string
example: Username
readOnly: true
-
SAML2Configuration:
type: object
properties:
@@ -2728,7 +2593,6 @@ components:
example: 'https://example.com/samlsso/meta'
manualConfiguration:
$ref: '#/components/schemas/SAML2ServiceProvider'
-
SingleSignOnProfile:
type: object
properties:
@@ -2740,23 +2604,18 @@ components:
- HTTP_POST
- HTTP_REDIRECT
- ARTIFACT
-
enableSignatureValidationForArtifactBinding:
type: boolean
description: Enables Signature validation for SAML Artifact Binding. Applicable only if SAML Artifact binding is enabled through the bindings option.
default: false
-
attributeConsumingServiceIndex:
type: string
readOnly: true
-
enableIdpInitiatedSingleSignOn:
type: boolean
default: false
-
assertion:
$ref: '#/components/schemas/SAMLAssertionConfiguration'
-
SAMLAttributeProfile:
type: object
properties:
@@ -2766,7 +2625,6 @@ components:
alwaysIncludeAttributesInResponse:
type: boolean
default: false
-
SingleLogoutProfile:
type: object
properties:
@@ -2787,7 +2645,6 @@ components:
- FRONTCHANNEL_HTTP_POST
idpInitiatedSingleLogout:
$ref: '#/components/schemas/IdpInitiatedSingleLogout'
-
IdpInitiatedSingleLogout:
type: object
properties:
@@ -2798,7 +2655,6 @@ components:
type: array
items:
type: string
-
SAMLAssertionConfiguration:
type: object
properties:
@@ -2806,7 +2662,6 @@ components:
type: string
default: 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'
example: 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'
-
audiences:
type: array
description: Additional audience values to be added to the SAML Assertions
@@ -2814,7 +2669,6 @@ components:
- 'https://app.example.com/saml'
items:
type: string
-
recipients:
type: array
description: Additional recipient values to be added to the SAML Assertions
@@ -2822,14 +2676,12 @@ components:
- 'https://app.example.com/saml'
items:
type: string
-
digestAlgorithm:
type: string
default: "http://www.w3.org/2000/09/xmldsig#sha1"
example: "http://www.w3.org/2000/09/xmldsig#sha1"
encryption:
$ref: '#/components/schemas/AssertionEncryptionConfiguration'
-
AssertionEncryptionConfiguration:
type: object
properties:
@@ -2842,7 +2694,6 @@ components:
keyEncryptionAlgorithm:
type: string
default: "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"
-
SAMLRequestValidation:
type: object
properties:
@@ -2851,7 +2702,6 @@ components:
default: true
signatureValidationCertAlias:
type: string
-
SAMLResponseSigning:
type: object
properties:
@@ -2860,13 +2710,11 @@ components:
default: true
signingAlgorithm:
type: string
-
SAML2ServiceProvider:
type: object
required:
- issuer
- assertionConsumerUrls
-
properties:
issuer:
type: string
@@ -2883,26 +2731,19 @@ components:
idpEntityIdAlias:
type: string
description: "Default value is the IdP Entity ID value specified in Resident IdP."
-
singleSignOnProfile:
$ref: '#/components/schemas/SingleSignOnProfile'
-
attributeProfile:
$ref: '#/components/schemas/SAMLAttributeProfile'
-
singleLogoutProfile:
$ref: '#/components/schemas/SingleLogoutProfile'
-
requestValidation:
$ref: '#/components/schemas/SAMLRequestValidation'
-
responseSigning:
$ref: '#/components/schemas/SAMLResponseSigning'
-
enableAssertionQueryProfile:
type: boolean
default: false
-
OpenIDConnectConfiguration:
type: object
required:
@@ -3065,6 +2906,8 @@ components:
type: string
replyTo:
type: string
+ replyToLogout:
+ type: string
WSTrustConfiguration:
type: object
required:
@@ -3137,7 +2980,6 @@ components:
type: integer
default: 1
example: 1
-
AuthenticationStepModel:
type: object
required:
@@ -3165,7 +3007,6 @@ components:
authenticator:
type: string
example: basic
-
AuthProtocolMetadata:
type: object
properties:
@@ -3323,7 +3164,6 @@ components:
type: array
items:
$ref: '#/components/schemas/ApplicationTemplatesListItem'
-
ApplicationTemplatesListItem:
type: object
properties:
@@ -3362,7 +3202,6 @@ components:
self:
type: string
example: "/t/wso2.com/api/server/v1/applications/templates/85e3f4b8-0d22-4181-b1e3-1651f71b88bd"
-
ApplicationTemplateModel:
type: object
properties:
@@ -3427,7 +3266,6 @@ components:
traceId:
type: string
example: e0fbcfeb-3617-43c4-8dd0-7b7d38e13047
-
servers:
- url: 'https://{serverUrl}/t/{tenantDomain}/api/server/v1'
variables:
diff --git a/en/identity-server/7.0.0/docs/apis/restapis/scim2-users.yaml b/en/identity-server/7.0.0/docs/apis/restapis/scim2-users.yaml
index 6a23feca32..1628d9123f 100644
--- a/en/identity-server/7.0.0/docs/apis/restapis/scim2-users.yaml
+++ b/en/identity-server/7.0.0/docs/apis/restapis/scim2-users.yaml
@@ -681,16 +681,39 @@ components:
$ref: '#/components/schemas/UserResponseObject'
UserSearchRequestObject:
type: object
- example:
+ properties:
schemas:
- - urn:ietf:params:scim:api:messages:2.0:SearchRequest
+ type: object
+ items:
+ type: string
+ example:
+ - urn:ietf:params:scim:api:messages:2.0:SearchRequest
attributes:
- - name.familyName
- - userName
- filter: userName sw ki and name.familyName co err
- domain: PRIMARY
- startIndex: 1
- count: 10
+ type: array
+ description: SCIM defined attributes parameter.
+ items:
+ type: string
+ example:
+ - name.familyName
+ - userName
+ filter:
+ type: string
+ description: The expression used for filtering. Supported filters are ew, eq, co, sw, and and.
+ example: userName sw ki and name.familyName co err
+ domain:
+ type: string
+ description: The name of the user store where filtering needs to be applied.
+ example: DEFAULT
+ startIndex:
+ type: integer
+ format: int32
+ description: The 1-based index of the first query result
+ example: 1
+ count:
+ type: integer
+ format: int32
+ description: Specifies the desired maximum number of query results per page.
+ example: 10
ErrorInvalidInput:
required:
- detail
diff --git a/en/identity-server/7.0.0/docs/apis/restapis/user-store.yaml b/en/identity-server/7.0.0/docs/apis/restapis/user-store.yaml
index 7a68c6df5d..f674b3f01f 100644
--- a/en/identity-server/7.0.0/docs/apis/restapis/user-store.yaml
+++ b/en/identity-server/7.0.0/docs/apis/restapis/user-store.yaml
@@ -352,7 +352,7 @@ paths:
-d '[
{
"operation": "REPLACE",
- "path": "/properties/disabled",
+ "path": "/properties/Disabled",
"value": "true"
}
]'
@@ -880,7 +880,7 @@ components:
path:
type: string
description: A JSON-Pointer
- example: /properties/disabled
+ example: /properties/Disabled
value:
type: string
description: The value to be used within the operations
diff --git a/en/identity-server/7.0.0/docs/assets/img/concepts/asgardeo-sdk.png b/en/identity-server/7.0.0/docs/assets/img/concepts/asgardeo-sdk.png
new file mode 100644
index 0000000000..b5e8eb3116
Binary files /dev/null and b/en/identity-server/7.0.0/docs/assets/img/concepts/asgardeo-sdk.png differ
diff --git a/en/identity-server/7.0.0/docs/assets/img/concepts/asgardeo-user-stores.png b/en/identity-server/7.0.0/docs/assets/img/concepts/asgardeo-user-stores.png
new file mode 100644
index 0000000000..59dc1ef44f
Binary files /dev/null and b/en/identity-server/7.0.0/docs/assets/img/concepts/asgardeo-user-stores.png differ
diff --git a/en/identity-server/7.0.0/docs/assets/img/concepts/login-flow-ai.png b/en/identity-server/7.0.0/docs/assets/img/concepts/login-flow-ai.png
new file mode 100644
index 0000000000..bce647931e
Binary files /dev/null and b/en/identity-server/7.0.0/docs/assets/img/concepts/login-flow-ai.png differ
diff --git a/en/identity-server/7.0.0/docs/assets/img/concepts/login-flow.png b/en/identity-server/7.0.0/docs/assets/img/concepts/login-flow.png
new file mode 100644
index 0000000000..c93053ee5f
Binary files /dev/null and b/en/identity-server/7.0.0/docs/assets/img/concepts/login-flow.png differ
diff --git a/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/bot-detection.png b/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/bot-detection.png
index 995165a76f..90874d9d31 100644
Binary files a/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/bot-detection.png and b/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/bot-detection.png differ
diff --git a/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png b/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png
index b3d4d36326..50d5cc865d 100644
Binary files a/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png and b/en/identity-server/7.0.0/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/accessing-protected-api.md b/en/identity-server/7.0.0/docs/complete-guides/react/accessing-protected-api.md
new file mode 100644
index 0000000000..3b32c514da
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/accessing-protected-api.md
@@ -0,0 +1,146 @@
+---
+template: templates/complete-guide.html
+heading: Accessing protected API from your React app
+read_time: 5 min
+---
+
+In this section, we will focus on how to call a secure API from your React app using the other token—the access token.
+
+For simplicity, let's assume that the APIs we’re calling are secured by the same Identity Provider (IdP) and use the same issuer— in this case, the same {{product_name}} organization. This is typical when React apps are interacting with internal APIs within the same organization.
+
+!!! tip "Tip"
+
+ If your app needs to call APIs secured by a different IdP, you’ll need to exchange your current access token for a new one issued by the IdP securing those APIs. This can be done using the OAuth2 token exchange grant type or other supported grant types. We will cover these scenarios in a separate guide.
+
+## Using SDK Built-in HTTP client
+
+You can use the `httpRequest` API provided by the Asgardeo SDK to make HTTP requests to these endpoints. This function is used to send http requests to {{product_name}} or desired backend. The developer doesn’t need to manually attach the access token since this function does it automatically.
+
+The following is a simple example of how you might use the Asgardeo SDK’s `httpRequest` to call a protected API endpoint, such as `/scim2/me` (to get the user profile details after signing in). In this case, the SCIM 2 endpoint is secured by the same {{product_name}} organization. {{product_name}} provides a SCIM 2 API for managing users within your organization. While user management with SCIM 2 is a topic for a different guide, we will use the API as part of our current guide.
+
+!!! note "Note"
+
+ The storage type must be set to `webWorker` for the token to be automatically attached. If it’s set to `sessionStorage` or `localStorage`, you may implement your own function for attaching the access token to the network request.
+
+```javascript
+
+const App = () => {
+
+
+ const { httpRequest } = useAuthContext();
+
+
+ const requestConfig = {
+ headers: {
+ "Accept": "application/json",
+ "Content-Type": "application/scim+json"
+ },
+ method: "GET",
+ url: "https://localhost:9443/scim2/me"
+ };
+
+
+ useEffect(() => {
+ // Make a GET request to a protected endpoint
+ httpRequest(requestConfig)
+ .then((response) => {
+ // Handle successful response
+ console.log('Response:', response.data);
+ })
+ .catch((error) => {
+ // Handle error
+ console.error('Error:', error);
+ });
+ }, [])
+}
+
+```
+
+Note that you don’t need to manually specify the Authorization header under headers in `requestConfig`, as `httpRequest` function intercepts the request and attaches the access token to the network request as the Authorization header.
+
+In the above example, the final request config sent by the `httpRequest` function would be as follows
+
+```javascript
+const requestConfig = {
+ headers: {
+ "Accept": "application/json",
+ "Content-Type": "application/scim+json",
+ "Authorization": "Bearer "
+ },
+ method: "GET",
+ url: "https://localhost:9443/scim2/me"
+ };
+
+
+```
+
+In case you want to send multiple API requests in parallel, you can use the `httpRequestAll` function to simultaneously trigger parallel network requests and receive responses after all network requests are completed.
+
+The following code snippet shows a javascript function which accepts a list of application IDs and sends multiple network requests for each app ID in parallel. The responses will contain results for each id, as an array of responses.
+
+```javascript
+import { AsgardeoSPAClient } from "@asgardeo/auth-react";
+
+
+const httpClientAll = AsgardeoSPAClient.getInstance()
+ .httpRequestAll.bind(AsgardeoSPAClient.getInstance());
+
+
+export const getApplicationsByIds = async (ids) => {
+
+
+ const requests = [];
+
+
+ for (const id of ids) {
+ requests.push({
+ headers: {
+ "Accept": "application/json",
+ "Content-Type": "application/json"
+ },
+ method: "GET",
+ url: "https://localhost:9443/applications/" + id
+ });
+ }
+
+
+ try {
+ const responses = await httpClientAll(requests);
+
+
+ return Promise.resolve(responses);
+ } catch (error) {
+ console.error(error);
+ }
+};
+
+```
+
+## Using a custom HTTP client
+
+In case you are not using the webWorker as the storage type, the `getAccessToken` function can be used to fetch the access token and manually attach it to the network request. The following is an example where the access token is fetched and manually attached to the authorization header of a Fetch request.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+
+
+const App = () => {
+ const { getAccessToken } = useAuthContext();
+
+
+ useEffect(() => {
+ getAccessToken().then(async (accessToken) => {
+ const response = await fetch("https://localhost:9443/scim2/me", {
+ "Authorization": "Bearer " + accessToken
+ })
+ console.log(response)
+ }).catch((error) => {
+ console.log(error);
+ });
+ }, []);
+
+ .
+ .
+ .
+}
+```
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/add-login-and-logout.md b/en/identity-server/7.0.0/docs/complete-guides/react/add-login-and-logout.md
new file mode 100644
index 0000000000..eed5718cef
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/add-login-and-logout.md
@@ -0,0 +1,79 @@
+---
+template: templates/complete-guide.html
+heading: Add login and logout to your app
+read_time: 5 min
+---
+
+Next, let’s implement login and logout for our React app. React hooks are a special type of functions that let you access state and other React features in React functional components. Asgardeo provides one such hook, `useAuthContext()`, to conveniently access user authentication data such as the logged in user’s information, etc and utility functions, such as a function to validate user’s authentication status, and retrieve access tokens.
+
+`useAuthContext` hook also provides us access with two key functions to perform sign in and sign out in your React application, `signIn` and `signOut` respectively. You can directly invoke the respective functions in our React application to trigger sign-in and sign-out requests as follows.
+
+Update the `App.jsx` with the following code.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+import './App.css';
+
+const App = () => {
+const { state, signIn, signOut } = useAuthContext();
+
+return (
+ <>
+ {
+ state.isAuthenticated
+ ?
+ :
+ }
+ >
+)
+};
+
+export default App;
+```
+
+Let’s look into the underlying details of what’s happening here.
+
+The `authConfig` object holds the configuration necessary for connecting the app to {{product_name}}. It includes properties like `signInRedirectURL` and `signOutRedirectURL`, which determine where users are redirected after signing in or out. The `clientID` identifies the application, and `baseUrl` specifies the {{product_name}} endpoint specific to your organization. The scope array lists the OAuth 2.0 permissions the app requires, such as `openid` and `profile`. The scops are used to indicate what user attributes are expected by our React app.
+
+The App component leverages the `useAuthContext` hook to access the authentication state (`state`) and actions (`signIn` and `signOut`). Inside the `AuthProvider`, the app conditionally renders a login or logout button based on whether the user is authenticated. If `state.isAuthenticated` is true, a "Logout" button is shown that triggers the `signOut` function. Otherwise, a "Login" button appears, which initiates the signIn process.
+
+Save the changes and re-run the application in development mode if it is not running already.
+
+```bash
+npm run dev
+```
+
+Once the application is started, you will see the homepage of the application with the changes we made.
+
+![Login screen]({{base_path}}/complete-guides/react/assets/img/image14.png){: width="800" style="display: block; margin: 0;"}
+
+Initiate Sign In
+Clicking on the login button will initiate an OIDC request. You will be able to observe the authorize request in the browser devtools as follows. To see this, right click on the application and click inspect and switch to the network tab. In the filter input, type “authorize”, and click on the sign in button.
+
+![OIDC request]({{base_path}}/complete-guides/react/assets/img/image15.png){: width="800" style="display: block; margin: 0;"}
+
+!!! tip "Tip"
+
+ The OpenID Connect specification offers several functions, known as grant types, to obtain an access token in exchange for user credentials. This example uses the authorization code grant type. In this process, the app first requests a unique code from the authentication server, which can later be used to obtain an access token. For more details on the authorization code grant type, please refer to the [{{product_name}} documentation.](https://is.docs.wso2.com/en/latest/guides/authentication/oidc/implement-auth-code-with-pkce/){:target="_blank"}
+
+{{product_name}} will receive this authorization request and respond by redirecting the user to a login page to enter their credentials.
+
+![OIDC request]({{base_path}}/complete-guides/react/assets/img/image16.png){: width="800" style="display: block; margin: 0;"}
+
+At this stage, **you need to create a [test user in {{product_name}}](https://is.docs.wso2.com/en/latest/guides/users/manage-users/#onboard-users){:target="_blank"} to try out the application.** Once you create a test user, you can enter the username and password of the test user to the login screen.
+
+If the login is successful, you should be able to see the application as shown below.
+
+![Login flow]({{base_path}}/complete-guides/react/assets/img/image17.png){: width="800" style="display: block; margin: 0;"}
+
+!!! tip "Tip"
+
+ **PKCE (Proof Key for Code Exchange)** is an addition to the OAuth2 specification to make the authorization code more immune to replay attacks. It is enabled by default for public clients such as our single page React application.
+
+ If you want to disable PKCE for some reason, you can do so via following the steps below. **However, disabling PKCE for public clients such as our single page React app is highly discouraged.**
+
+ 1. Log in to the {{product_name}} console and select the application you created.
+ 2. Switch to the Protocol tab.
+ 3. Uncheck the Mandatory checkbox under PKCE section.
+
+In this section, we have added login and logout features to our React app. In the next step, we will look into how to access the user attributes of the logged in user.
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image1.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image1.png
new file mode 100644
index 0000000000..c4be223ec5
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image1.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image10.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image10.png
new file mode 100644
index 0000000000..b88ab5e4a7
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image10.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image11.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image11.png
new file mode 100644
index 0000000000..df87556597
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image11.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image12.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image12.png
new file mode 100644
index 0000000000..ab1b9c4f8f
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image12.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image13.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image13.png
new file mode 100644
index 0000000000..0acfd4b6fb
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image13.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image14.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image14.png
new file mode 100644
index 0000000000..d758aefaa3
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image14.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image15.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image15.png
new file mode 100644
index 0000000000..4cccdbec5c
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image15.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image16.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image16.png
new file mode 100644
index 0000000000..d8a814ccf7
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image16.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image17.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image17.png
new file mode 100644
index 0000000000..1f5f1092f8
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image17.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image18.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image18.png
new file mode 100644
index 0000000000..a383eabaac
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image18.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image19.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image19.png
new file mode 100644
index 0000000000..dc5197602d
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image19.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image2.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image2.png
new file mode 100644
index 0000000000..f9f9ba0fc4
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image2.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image20.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image20.png
new file mode 100644
index 0000000000..0972bac78b
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image20.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image3.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image3.png
new file mode 100644
index 0000000000..39a39a130b
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image3.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image4.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image4.png
new file mode 100644
index 0000000000..2b9c046ef1
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image4.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image5.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image5.png
new file mode 100644
index 0000000000..b5b9bdb6ca
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image5.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image6.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image6.png
new file mode 100644
index 0000000000..1996cbd1dc
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image6.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image7.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image7.png
new file mode 100644
index 0000000000..932561f25a
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image7.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image8.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image8.png
new file mode 100644
index 0000000000..c8dfe9d415
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image8.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image9.png b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image9.png
new file mode 100644
index 0000000000..9d3f3610a2
Binary files /dev/null and b/en/identity-server/7.0.0/docs/complete-guides/react/assets/img/image9.png differ
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/create-a-react-app.md b/en/identity-server/7.0.0/docs/complete-guides/react/create-a-react-app.md
new file mode 100644
index 0000000000..60b81acd38
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/create-a-react-app.md
@@ -0,0 +1,35 @@
+---
+template: templates/complete-guide.html
+heading: Create a React app
+read_time: 5 min
+---
+
+For this guide, you will be creating a simple React app using [Vite](https://vitejs.dev/){:target="_blank"}, a modern, fast and lightweight tool that helps you quickly set up and develop modern JavaScript apps.
+
+Open a terminal, change directory to where you want to initialize the project, and run the following command to create your first React sample app.
+
+
+```bash
+npm create vite@latest is-react -- --template react
+```
+
+Running this command will create a folder with a ready-to-run boilerplate React project, with a development server to run the project and instantly reload changes to the project in your browser without manual refresh.
+
+Once the application is created, install the dependencies using the following command.
+
+```bash
+cd is-react
+npm install
+```
+
+Then run the sample in the development mode. This allows you to see real-time updates and debug the app as you make changes.
+
+```bash
+npm run dev
+```
+
+Confirm that the dev server is up and running by verifying the output in the terminal. Then, navigate to [http://localhost:5173](http://localhost:5173){:target="_blank"} and you should see the sample app working in the browser.
+
+![Navigate to localhost]({{base_path}}/complete-guides/react/assets/img/image6.png){: width="600" style="display: block; margin: 0;"}
+
+At this point, you have a simple yet fully functional React app. In the next step, let’s try to integrate an OIDC SDK with the app.
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/display-logged-in-user-details.md b/en/identity-server/7.0.0/docs/complete-guides/react/display-logged-in-user-details.md
new file mode 100644
index 0000000000..7a23ffdaec
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/display-logged-in-user-details.md
@@ -0,0 +1,133 @@
+---
+template: templates/complete-guide.html
+heading: Display logged-in user details
+read_time: 5 min
+---
+
+At this point, we’ve successfully implemented login and logout capabilities using the Asgardeo React SDK. The next step is to explore how to access and display logged-in user details within the app. The Asgardeo React SDK loads the basic user attribute details to the authentication state, so that you can directly access those from the state (such as `state.username`) and use them in the application. First, let’s try to display the username using state.username.Replace the code in app.jsx with the following.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+import './App.css';
+
+const App = () => {
+ const { state, signIn, signOut } = useAuthContext();
+
+ return (
+ <>
+ {
+ state.isAuthenticated
+ ? <>
+
Welocme {state.username}
+
+ >
+ :
+ }
+ >
+ )
+};
+
+export default App;
+```
+
+If your React application is already running in the development mode, the home page will be reloaded and you will see the updated user interface.
+
+![Logout screen]({{base_path}}/complete-guides/react/assets/img/image18.png){: width="800" style="display: block; margin: 0;"}
+
+There may be instances where you’d need to retrieve user attributes outside React components. Asgardeo React SDK provides a [getBasicUserInfo](https://github.com/asgardeo/asgardeo-auth-react-sdk/blob/main/API.md#getbasicuserinfo){:target="_blank"} function, which allows you to retrieve the authenticated user’s basic information. The code example in the following section demonstrates this process and can be adapted to fit your application with any necessary customizations.
+
+Again, replace the code in `app.jsx` with the following.
+
+```javascript
+import { useAuthContext } from "@asgardeo/auth-react";
+import { useEffect, useState } from "react";
+import './App.css';
+
+const App = () => {
+
+ const { state, getBasicUserInfo, signIn, signOut } = useAuthContext();
+ const [userInfo, setUserInfo] = useState(undefined);
+
+ useEffect(() => {
+ getBasicUserInfo().then((response) => {
+ setUserInfo(response)
+ }).catch((error) => {
+ console.error(error);
+ });
+ }, [state]);
+
+
+ return (
+ <>
+ {
+ state.isAuthenticated
+ ? <>
+
Welcome {userInfo?.username}
+
+ >
+ :
+ }
+ >
+ )
+};
+
+export default App;
+```
+
+The above code snippet, the app utilizes the `useAuthContext` hook to access authentication state and methods such as `getBasicUserInfo`, `signIn`, and `signOut`. It also uses React's `useState` to store basic user information and `useEffect` to fetch this information whenever the authentication state changes. If the user is authenticated, the app displays a welcome message with the username and a button to log out. If the user is not authenticated, it shows a login button that triggers the sign-in process, and the errors during user info retrieval are handled by logging them to the console.
+
+Similarly, you can access the other user attributes, such as email, display name, allowed scopes, etc as well. The following code snippet shows you how you can access them in your app. Asgardeo React SDK is responsible for processing the ID token and decoding these attributes.
+
+```javascript
+
Your email: { userInfo?.email }
+
Display name: { userInfo?.displayName }
+
Allowed scopes: { userInfo?.allowedScopes }
+
Tenant domain: { userInfo?.tenantDomain }
+
Session state: { userInfo?.sessionState }
+```
+
+## Getting additional user attributes
+
+Other than the above attributes decoded and available to you by default, Asgardeo React SDK provides [getDecodedIDToken](https://github.com/asgardeo/asgardeo-auth-react-sdk/blob/main/API.md#getdecodedidtoken){:target="_blank"} method to access any other user attributes that are not exposed by `getBasicUserInfo`. This method will decode the ID token in browser storage and return the output as a JSON object.
+
+To get additional user attributes to the ID token, the application should be configured to request the specific user attributes at the time of login. For example, if you want to retrieve a user's mobile number as an attribute, you need to configure the application to request the user’s mobile number as an attribute in the ID token.
+
+1. Log in to the {{product_name}} console and select the application you created.
+2. Go to the **User Attributes** tab.
+3. Select the **phone** scope.
+4. Expand the scope, and you will see that all attributes under this scope (e.g., `mobile_number`) are selected.
+5. Click Update to save the changes.
+
+```javascript
+
+const { state, signIn, signOut, getDecodedIDToken } = useAuthContext();
+
+
+const [mobileNumber, setMobileNumber] = useState("")
+
+
+useEffect(() => {
+ if (state.isAuthenticated) {
+ getDecodedIDToken().then((decodedIdToken) => {
+ console.log(decodedIdToken);
+ setMobileNumber(decodedIdToken.phone_number)
+ }).catch((error) => {
+ console.log(error);
+ })
+ }
+}, [ state.isAuthenticated ]);
+
+
+return (
+ <>
+
Your mobile number: {mobileNumber}
+ >
+)
+
+```
+
+In the above code snippet, we run the `getDecodedIDToken` method if the user is authenticated, and print the output to the browser console. The decoded ID token response will be printed to the browser console as follows.
+
+![ID token]({{base_path}}/complete-guides/react/assets/img/image19.png){: width="800" style="display: block; margin: 0;"}
+
+In this step, we further improved our React app to display the user attributes. As the next step, we will try to secure routes within the app.
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/install-asgardeo-sdk.md b/en/identity-server/7.0.0/docs/complete-guides/react/install-asgardeo-sdk.md
new file mode 100644
index 0000000000..8648119c9c
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/install-asgardeo-sdk.md
@@ -0,0 +1,78 @@
+---
+template: templates/complete-guide.html
+heading: Install and configure Asgardeo SDK
+read_time: 5 min
+---
+
+## Install @asgardeo/auth-react
+
+The Asgardeo React SDK is a production-ready SDK that simplifies integrating {{product_name}} as an Identity Provider in your React applications. It provides essential features like user authentication, retrieving user information, and an HTTP client for sending network requests with attached tokens. Additionally, it ensures best practices by being Secure by Design and Secure by Default.
+
+
+!!! Info
+
+ Asgardeo-branded SDKs can be used to build apps to work with the all [WSO2 identity suite](https://wso2.com/identity-and-access-management/){:target="_blank"} of products that includes [WSO2 Identity Server (WSO2 IS)](https://wso2.com/identity-server/){:target="_blank"}, [WSO2 Private Identity Cloud (WSO2 PIC)](https://wso2.com/private-identity-cloud/){:target="_blank"} and [Asgardeo](https://wso2.com/asgardeo/){:target="_blank"}.
+
+!!! Info
+
+ Asgardeo React SDK has been developed on open standards such as OAuth2, OpenID Connect etc, therefore you can use the Asgardeo React SDK for adding authentication to your application with any other OpenID Connect identity provider.
+
+
+As the next step, run the following command to install the React SDK from the npm registry.
+
+```bash
+npm install @asgardeo/auth-react
+
+```
+
+## Add `` to your app
+
+During the previous step, we have added Asgardeo React SDK as a dependency in our app. Now we are going to use the `` component from the Asgardeo React SDK which is built on top of [React Context](https://react.dev/learn/passing-data-deeply-with-context){:target="_blank"}. The `` serves as a context provider for user login in the app. You can add the `` to your app by wrapping the root component to access authentication-related capabilities throughout the component tree.
+
+First, you need to open the project using an IDE such as VS Code. Then, as shown below, you need to wrap the **** component in `main.jsx` with the `` component. Make sure to replace the placeholders in this code from the configuration parameters that we generated in [step-3](http://localhost:8000/asgardeo/docs/complete-guides/react/register-an-application/).
+
+```javascript
+import React from 'react';
+import ReactDOM from 'react-dom/client';
+import App from './App.jsx';
+import { AuthProvider } from '@asgardeo/auth-react';
+import './index.css';
+
+const config = {
+ signInRedirectURL: "http://localhost:5173",
+ signOutRedirectURL: "http://localhost:5173",
+ clientID: "",
+ baseUrl: "https://localhost:9443",
+ scope: [ "openid","profile" ]
+}
+
+ReactDOM.createRoot(document.getElementById('root')).render(
+
+
+
+
+,
+);
+
+```
+
+As shown above, we used `` at the root level of the application to ensure that all components can interact with the authentication logic provided by {{product_name}}. It takes the configuration object with the following values for the single page application defined in the {{product_name}} console. You can copy these values from the {{product_name}} console.
+
+| Parameter | Description | Example |
+|-----------------------|----------------------------------------------------------------------------------------------------------------------|-----------------------------------|
+| signInRedirectURL | The URL to redirect the user to after successfully signing in. This URL should be an absolute URL and only accessible to authenticated users. | `http://localhost:5173` |
+| signOutRedirectURL | The URL to redirect the user to after signing out. This should be an absolute URL and should be accessible without authentication. | `http://localhost:5173/login` |
+| clientID | The client ID of the created OIDC application | - |
+| baseUrl | The base URL of the Identity Provider API. This depends on the identity provider you are using. For {{product_name}}, this can be obtained from your application settings in the {{product_name}} console. | `https://localhost:9443` |
+| scope | Specifies the required application scopes as a list. In this guide, we need access to user details, so we will request the 'profile' scope. | `[ "profile" ]` |
+
+!!! Info
+
+ If you’re familiar with OAuth2 or OIDC, you might notice that there’s no client secret involved here. This is because, according to the OAuth2 specification, our React app is classified as a public client. Since it runs on user devices and cannot securely store credentials, the Identity Provider (IdP) should not authenticate public clients before issuing access tokens. The Asgardeo SDK addresses this by implementing the PKCE (Proof Key for Code Exchange) extension, which helps mitigate the security risks associated with public clients
+
+Here’s a brief overview of what `` provides:
+
+* **Context Management:** It creates a context that holds the authentication state and methods to handle authentication actions like logging in, logging out, and checking the user's authentication status.
+* **Session Handling:** `` manages user sessions, including token storage and retrieval, token refresh, and user session expiration handling.
+* **Easy Access to Authentication:** By wrapping your app with ``, any component within your app can easily access authentication details and actions using hooks like useAuthContext.
+* **Initialization and Configuration:** It initializes the SDK with the necessary configuration, such as client ID, server endpoints, and other authentication settings.
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/introduction.md b/en/identity-server/7.0.0/docs/complete-guides/react/introduction.md
new file mode 100644
index 0000000000..b5981efa59
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/introduction.md
@@ -0,0 +1,47 @@
+---
+template: templates/complete-guide.html
+heading: Introduction
+read_time: 2 mins
+---
+React is a widely used JavaScript library designed for creating dynamic single-page apps (SPAs). It enables developers to build responsive interfaces by breaking down complex UIs into reusable components. Unlike traditional UI technologies, React updates specific parts of the page without re-rendering the entire page, thanks to its virtual DOM. This capability makes React popular for developing SPAs.
+
+Implementing login functionality in your React app is essential for managing user access, personalizing user experiences, and securing the app. It enhances user experience, protects user data, boosts engagement, and helps ensure regulatory compliance.
+
+!!! Info
+
+ Asgardeo-branded SDKs can be used to build apps to work with the all [WSO2 identity suite](https://wso2.com/identity-and-access-management/){:target="_blank"} of products that includes [WSO2 Identity Server (WSO2 IS)](https://wso2.com/identity-server/){:target="_blank"}, WSO2 [Private Identity Cloud (WSO2 PIC)](https://wso2.com/private-identity-cloud/){:target="_blank"} and [Asgardeo](https://wso2.com/asgardeo/){:target="_blank"}.
+
+
+## Learning objectives
+
+This guide will walk you through everything you need to know about securing React apps, including implementing user login in your React app, integrating it with an Identity Provider (IdP) to make the login process simple and secure, and general guidelines to protect your end users. It also covers how to make secure API calls to an OAuth2-protected API within your React app.
+
+In this guide, you will:
+
+* Register an application in {{product_name}}
+* Create a React app
+* Install Asgardeo React SDK
+* Add login and logout to your app
+* Display logged in user detail
+* Securing routes within the app
+* Accessing protected API from your React app
+* Managing tokens in your React app
+
+
+!!! tip "Tip"
+
+ This guide takes approximately 60 minutes to complete and covers everything required to add user login and secure your React apps. If you’re looking for a shorter guide, try the [React Quick Start guide](https://is.docs.wso2.com/en/latest/quick-starts/react/){:target="_blank"}, which takes around 15 minutes to complete.
+
+
+!!! tip "Tip"
+
+ If you are already familiar with the concepts discussed in the guide, you can use the Asgardeo React template to bootstrap your application by running the following command.
+
+ ```bash
+
+ npx tmplr --dir my-vite-react-app asgardeo/asgardeo-vite-react-template
+
+ ```
+ The Asgardeo React template generates a ready-made React sample app with pre-configured login and logout capabilities, helping you kick-start your project in just 2 minutes.
+
+ All you need is a `client_id`, which you can obtain by registering a **Single Page Application** in {{product_name}}.
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/manage-tokens-in-React-apps.md b/en/identity-server/7.0.0/docs/complete-guides/react/manage-tokens-in-React-apps.md
new file mode 100644
index 0000000000..fbc6146d9b
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/manage-tokens-in-React-apps.md
@@ -0,0 +1,135 @@
+---
+template: templates/complete-guide.html
+heading: Manage tokens in React apps
+read_time: 5 min
+---
+
+## Token Validation
+
+A key principle of security tokens is that the receiver must first validate the token. This involves checking the authenticity of the token issuer, ensuring the token meets validity criteria such as expiration time, and confirming that the receiver is authorized to use the token. The Asgardeo React SDK handles token validation automatically as part of its authentication and session management process to ensure that users have valid and unexpired tokens when accessing protected resources.
+
+When a user signs in, the Asgardeo React SDK acquires an access token (and often an ID token) from {{product_name}}. The access token is by default an opaque token and the ID token is in the form of JSON Web Tokens (JWTs). The SDK automatically validates the token when it is obtained. This involves several checks:
+
+- **Signature Validation:** The SDK verifies the JWT's signature using the public key retrieved from {{product_name}} JWKS endpoint. This ensures that the token has been issued by a trusted authority and has not been tampered with.
+
+- **Expiration Check:** The SDK checks the `exp` (expiration) claim in the token to ensure it has not expired. Tokens are time-bound, and once the expiration time is reached, the token is considered invalid.
+
+- **Issuer Validation:** The SDK verifies that the `iss` (issuer) claim in the token matches the expected issuer URL, which is typically the base URL specified in the `authConfig`.
+
+- **Audience Validation:** The SDK checks the aud (audience) claim to ensure the token is intended for your application (identified by the `clientID` in your `authConfig`).
+
+If the token is close to being expired, the SDK will automatically attempt to renew the token by performing a silent sign-in (explained below). This helps maintain a seamless user experience without requiring the user to re-authenticate frequently. If the token has already expired and cannot be renewed silently, the user will be redirected to the login page to obtain a new token.
+
+## Token Persistence
+
+In the Asgardeo React SDK, the state storage mechanism determines where the authentication state, tokens, and other related data are stored. By default, Asgardeo React SDK uses session storage, but you can configure the SDK to use other storage options like local storage or even a web worker.
+
+You can specify the storage mechanism in the authConfig object using the storage property. Here's how you can configure it for different storage types.
+
+- **Local Storage:** localStorage stores data across browser sessions, meaning the data persists even after the browser is closed and reopened.
+
+```javascript
+
+const authConfig = {
+ // other configs
+ storage: "localStorage"
+}
+
+```
+
+- **Session Storage:** sessionStorage stores data for the duration of the page session. The data is cleared when the page session ends (e.g., when the tab is closed).
+
+```javascript
+
+const authConfig = {
+ // other configs
+ storage: "sessionStorage"
+}
+
+
+```
+
+- **Web Worker:** Using a web worker allows state to be managed in a separate thread, which can be beneficial for performance and security.
+
+```javascript
+
+const authConfig = {
+ // other configs
+ storage: "webWorker"
+}
+
+```
+
+Compared to other methods for persisting tokens, web workers are the most secure option, due to the following reasons.
+
+- **Performance**: Web workers run in a separate thread from the main JavaScript execution, offloading tasks like handling authentication state, which reduces the load on the main thread and leads to smoother UI interactions.
+
+- **Security:** Operating in isolation from the DOM, web workers reduce the risk of cross-site scripting (XSS) attacks by keeping sensitive authentication data secure.
+
+- **Asynchronous** Task Management: Web workers enhance the handling of asynchronous tasks, such as token renewal or data fetching, without blocking the main thread.
+
+- **Scalability:** By enabling parallelism, web workers make applications more responsive and better equipped to handle multiple concurrent operations.
+
+## Initiate Logout
+
+The Asgardeo React SDK provides a simple approach to handle user logout from your app. When a user logs out, the SDK ensures that both the local session and the session on the {{product_name}} are terminated, ensuring a complete and secure logout process and you don’t need to worry on cleanup activities
+
+When a user initiates log out, the following steps typically occur.
+
+- **Local Session Termination:** The SDK clears any locally stored credentials, such as the access token and the ID token, which are used to maintain the user's authentication state within the application. This effectively logs the user out of the application locally.
+
+- **Redirection to {{product_name}} for sign out:** After clearing the local session, the SDK redirects the user to the sign-out endpoint of your {{product_name}} organization. This ensures that the user is also signed out globally from {{product_name}}. It’s particularly important in single sign-on (SSO) scenarios where the user might be logged into multiple applications under the same identity.
+
+- **Post Sign-Out Redirection:** Once the global sign-out is complete, the user is redirected back to a specified URL, usually the application's homepage or a custom logout page, which is configured in the SDK's authConfig under signOutRedirectURL.
+
+## Silent Sign In
+
+Silent login allows an app to check if a user is already authenticated, either through a session cookie or a token stored in the browser, and re-authenticate automatically in the background. To implement silent sign-in using the Asgardeo React SDK, you can leverage the library's built-in support for token renewal and session management. Here's how you can do it:
+
+- **Configure the Silent Sign-In:** Ensure that your `authConfig` is set up to allow silent sign-in. You need to configure the prompt parameter to `none` when initiating a silent sign-in request. This instructs the identity provider to not display any login prompts and to rely on existing sessions instead.
+
+- **Use the SDK’s Built-in Functionality:** The Asgardeo React SDK typically handles silent token renewal automatically if the configuration is set correctly. When the access token is about to expire, the SDK will attempt to renew it silently in the background.
+
+- **Handling Token Expiry:** In your React components, you can handle token expiry by checking the authentication state and initiating a silent sign-in if the user’s session is still valid but the token has expired.
+
+```javascript
+
+import { AuthProvider, useAuthContext } from "@asgardeo/auth-react";
+
+
+const authConfig = {
+ signInRedirectURL: "http://localhost:5173",
+ signOutRedirectURL: "http://localhost:5173",
+ clientID: "",
+ baseUrl: "https://localhost:9443",
+ scope: ["openid", "profile"],
+ enableSilentSignIn: true
+};
+
+
+const App = () => {
+ const { state, signIn } = useAuthContext();
+
+
+ React.useEffect(() => {
+ if (!state.isAuthenticated) {
+ signIn({ prompt: "none" }).catch(() => {
+ // Handle silent sign-in failure
+ });
+ }
+ }, [state.isAuthenticated, signIn]);
+
+
+ return (
+
+ {/* App content */}
+
+ )
+}
+
+
+export default App;
+useAuthContext
+
+
+```
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/next-steps.md b/en/identity-server/7.0.0/docs/complete-guides/react/next-steps.md
new file mode 100644
index 0000000000..d19939338f
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/next-steps.md
@@ -0,0 +1,55 @@
+---
+template: templates/complete-guide.html
+heading: Next Steps
+read_time: 1 min
+---
+
+This guide you just have completed, covered the adding user login for React apps by integrating with an Identity Provider (IdP) and additional use cases such making calls to an OAuth2-protected API.
+
+!!! tip "Tip"
+
+ As you are now familiar with the concepts discussed in the guide, you can use the Asgardeo React template to bootstrap your application by running the following command.
+
+ ```bash
+
+ npx tmplr --dir my-vite-react-app asgardeo/asgardeo-vite-react-template
+
+ ```
+ The Asgardeo React template generates a ready-made React sample app with pre-configured login and logout capabilities, helping you kick-start your project in just 2 minutes.
+
+ All you need is a `client_id`, which you can obtain by registering a **Single Page Application** in {{product_name}}.
+
+
+
+
+
+Now that your React application is secured with authentication features integrated, It is time to explore the additional features {{product_name}} offers to make the login flow more diverse and secure.
+
+- [Multi factor authentication](https://is.docs.wso2.com/en/latest/guides/authentication/mfa/){:target="_blank"}
+- [Passwordless authentication](hhttps://is.docs.wso2.com/en/latest/guides/authentication/passwordless-login/){:target="_blank"}
+- [Self registration](https://is.docs.wso2.com/en/latest/guides/account-configurations/user-onboarding/self-registration/){:target="_blank"}
+- [Login UI customization](https://is.docs.wso2.com/en/latest/guides/branding/){:target="_blank"}
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/prerequisite.md b/en/identity-server/7.0.0/docs/complete-guides/react/prerequisite.md
new file mode 100644
index 0000000000..c18add16c9
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/prerequisite.md
@@ -0,0 +1,18 @@
+---
+template: templates/complete-guide.html
+heading: Prerequisite
+read_time: 1 mins
+---
+
+## Before you start, ensure you have the following:
+
+* About 60 minutes
+* {{product_name}} setup
+* [Node.js](https://nodejs.org/en/download/package-manager){:target="_blank"} v18+ and npm
+* A favorite text editor or IDE
+
+
+!!! note "Note"
+
+ You need to have installed [Node.js](https://nodejs.org/en/download/package-manager){:target="_blank"} v18+ and npm (which comes inbuilt with Node) to run this sample. Although Node.js is primarily a server-side language,it needs to have been installed to manage dependencies and run scripts for our project.
+
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/register-an-application.md b/en/identity-server/7.0.0/docs/complete-guides/react/register-an-application.md
new file mode 100644
index 0000000000..ee90c651bb
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/register-an-application.md
@@ -0,0 +1,39 @@
+---
+template: templates/complete-guide.html
+heading: Register an application in Asgardeo
+read_time: 2 min
+---
+
+First unless you already have done that, you need to setup {{product_name}} and register your application as a single page application.
+
+* Download and [setup WSO2 Identity Server](https://is.docs.wso2.com/en/latest/get-started/quick-set-up/){:target="_blank"}
+* Sign into {{product_name}} console and navigate to **Applications > New Application.**
+* Select Single Page Application
+
+![Select Single Page Application]({{base_path}}/complete-guides/react/assets/img/image5.png){: width="600" style="display: block; margin: 0;"}
+
+Next, complete the wizard popup by providing a suitable name and an authorized redirect URL.
+
+!!! Example
+ name: is-react
+
+ Authorized redirect URL: http://localhost:5173*
+
+
+
+![Register a new application]({{base_path}}/complete-guides/react/assets/img/image8.png){: width="600" style="display: block; margin: 0;"}
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use [http://localhost:5173](http://localhost:5173){:target="_blank"}, as the sample app will be accessible at this URL.
+
+
+
+You will need the following information for the `AuthProvider` config.
+
+* Client ID
+* Redirect URL
+
+![Quick start guide]({{base_path}}/complete-guides/react/assets/img/image9.png){: width="600" style="display: block; margin: 0;"}
+
+In this step, we have ve registered our React app as an application in the {{product_name}} console and generated the required metadata. Next, we will create a React app using Vite.
diff --git a/en/identity-server/7.0.0/docs/complete-guides/react/securing-routes-within-the-app.md b/en/identity-server/7.0.0/docs/complete-guides/react/securing-routes-within-the-app.md
new file mode 100644
index 0000000000..5aa7e2304b
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/complete-guides/react/securing-routes-within-the-app.md
@@ -0,0 +1,131 @@
+---
+template: templates/complete-guide.html
+heading: Securing Routes within the app
+read_time: 5 min
+---
+
+In a React app, routes define the paths within the application that users can navigate to, linking URLs to specific components. Securing routes is essential to protect sensitive data, prevent unauthorized access, and ensure that only authenticated users can access certain parts of the application. In this section, let’s look at how we can secure routes using Asgardeo React SDK
+
+The Asgardeo SDK provides multiple approaches to secure routes in your application. Here we will demonstrate how to secure routes in a single-page React app using [React Router v6](https://reactrouter.com/en/main){:target="_blank"} , the most popular routing library for React. The same approach can be applied to other routing libraries such as [TanStack Router](https://tanstack.com/router/latest){:target="_blank"} and [Wouter](https://github.com/molefrog/wouter){:target="_blank"}, etc.
+
+## Using ``
+
+Asgardeo React SDK provides the `SecureApp` component, using which you can wrap the whole app or a part of the app that needs to have secure access. Then all the views wrapped with the SecureApp component are not accessible to an unauthenticated user.
+
+```javascript
+
+
+ }
+ onSignIn={ onSignInFunction }
+ overrideSignIn={ overrideSignInFunction }
+ >
+
+
+
+
+```
+
+In the above example, the `SecureApp` component wraps the entire App component, restricting all unauthorized users from accessing any part of our React application. It displays a fallback UI component while the authentication status is being resolved, and accepts a callback function to trigger after the sign in is successful.
+
+## Using ``
+
+`AuthenticatedComponent` is another component provided by the Asgardeo React SDK to conditionally display UI elements based on the user's authentication status. You can use this to implement secure routes with react router in our app.
+
+```javascript
+
+import { AuthProvider } from '@asgardeo/auth-react'
+import { BrowserRouter as Router, Routes, Route } from 'react-router-dom'
+import LoginPrompt from './components/login-prompt'
+import Home from './pages/home'
+import Dashboard from './pages/dashboard'
+import './App.css'
+
+const config = {
+ signInRedirectURL: "http://localhost:5173",
+ signOutRedirectURL: "http://localhost:5173",
+ clientID: "0Fo7kLavZtHAVtXRr1zzpjwzeBMa",
+ baseUrl: "https://localhost:9443",
+ scope: [ "openid","profile" ]
+}
+
+function App() {
+
+ return (
+ Initializing...}>
+
+
+ } />
+
+
+
+ }
+ />
+
+
+
+ )
+}
+
+export default App
+
+```
+
+This code snippet defines a route in a React application using the Route component from react-router-dom. It specifies that when the user navigates to the /dashboard path, the AuthenticatedComponent should be rendered. Let’s break down the code to understand what’s going on behind the scenes.
+
+- `path="/dashboard"`: This sets the URL path for this route. When the user visits `/dashboard`, the specified component will be rendered.
+
+- `element={...}`: defines the component(s) that will be rendered for this route. In this case, it’s the Dashboard UI view wrapped with AuthenticatedComponent.
+
+- `AuthenticatedComponent`: This is a React component provided by the Asgardeo React SDK that checks if the user is authenticated. It wraps around the Dashboard component to secure it.
+
+- `fallbackComponent={LoginPrompt}`: If the user is not authenticated, the AuthenticatedComponent will render the LoginPrompt component instead of the Dashboard component, prompting the user to log in.
+
+- ``: This is the main component that will be rendered if the user is authenticated and has access to the /dashboard route.
+
+## Bring your own implementation
+
+If you prefer to have full control over how the app routes should be secured—for example, if you want to run custom application logic before enabling or disabling a route—you can also build a completely custom logic using the primitives provided by the Asgardeo React SDK out of the box.
+
+```javascript
+
+const App = () => {
+
+ const ProtectedRoute = ({ children }: { children: ReactNode }) => {
+
+
+ const { state } = useAuthContext();
+
+
+ if (!state.isAuthenticated) {
+ return ;
+ }
+
+
+ return children;
+ };
+
+
+ return (
+
+
+
+
+ }
+ />
+ } />
+ } />
+
+ )
+};
+
+
+```
+
+In this step, we looked into how to secure component routes within a React app. Next, we will try to access a protected API from our React app, which is a common requirement for SPAs.
diff --git a/en/identity-server/7.0.0/docs/concepts/add-login.md b/en/identity-server/7.0.0/docs/concepts/add-login.md
new file mode 100644
index 0000000000..bea0e89133
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/concepts/add-login.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/add-login.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/concepts/api-security.md b/en/identity-server/7.0.0/docs/concepts/api-security.md
new file mode 100644
index 0000000000..ed3be72922
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/concepts/api-security.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/api-security.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/concepts/basic-concepts.md b/en/identity-server/7.0.0/docs/concepts/basic-concepts.md
new file mode 100644
index 0000000000..5d7d7595d9
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/concepts/basic-concepts.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/basic-concepts.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/concepts/customer-iam.md b/en/identity-server/7.0.0/docs/concepts/customer-iam.md
new file mode 100644
index 0000000000..abec1a16fe
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/concepts/customer-iam.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/customer-iam.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/concepts/index.md b/en/identity-server/7.0.0/docs/concepts/index.md
new file mode 100644
index 0000000000..66813dff99
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/concepts/index.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/index.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/concepts/workforce-iam.md b/en/identity-server/7.0.0/docs/concepts/workforce-iam.md
new file mode 100644
index 0000000000..05a302add4
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/concepts/workforce-iam.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/workforce-iam.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-datasource-bpsds.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-datasource-bpsds.md
deleted file mode 100644
index b4f05c586e..0000000000
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-datasource-bpsds.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# Change the Default Datasource for BPS
-
-This document guides you to change the underlying databases that are
-used in business process service(BPS) components.
-
-By default WSO2 Identity Server uses the Embedded H2 database as the BPS
-datasource. However, you can change this to any database type that is
-supported by WSO2 Identity Server.
-
-Following are the sample configuration for each database type.
-
-??? example "PostgreSQL"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:postgresql://localhost:5432/gregdb"
- username = "regadmin"
- password = "regadmin"
- driver = "org.postgresql.Driver"
-
- [bps_database.config.pool_options]
- defaultAutoCommit=true
- commitOnReturn=true
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/postgresql.sql` file against the created database.
-
-??? example "MySQL"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:mysql://localhost:3306/IAMtest?useSSL=false"
- username = "root"
- password = "root"
- driver = "com.mysql.jdbc.Driver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/mysql.sql` file against the created database.
-
-
-??? example "DB2"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:db2://192.168.108.31:50000/test"
- username = "db2inst1"
- password = "db2inst1"
- driver = "com.ibm.db2.jcc.DB2Driver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/db2.sql` file against the created database.
-
-
-??? example "MSSQL"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:sqlserver://localhost:1433;databaseName=test;SendStringParametersAsUnicode=false"
- username = "sa"
- password = "pass#word2"
- driver = "com.microsoft.sqlserver.jdbc.SQLServerDriver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/mssql.sql` file against the created database.
-
-
-??? example "Oracle"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:oracle:thin:@localhost:1521/ORCLPDB"
- username = "IS590Test"
- password = "ora12c"
- driver = "oracle.jdbc.OracleDriver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/oracle.sql` file against the created database.
-
-
-**Advanced BPS Database Configurations**
-
-Apart from the above basic configurations, WSO2 Identity Server supports the following advanced BPS database configurations.
-
- ``` toml
- [bps_database.config.pool_options]
- maxActive = "50"
- maxWait = "60000"
- minIdle = "5"
- testOnBorrow = true
- validationInterval = "30000"
- validationQuery = "SELECT 1; COMMIT"
- ```
-
-The descriptions for the advanced configurations can be found in the [Performance Tuning]({{base_path}}/deploy/performance/performance-tuning-recommendations/#jdbc-pool-configuration) documentation.
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md
index 7336c405b1..ab5e289c8b 100644
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md
+++ b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md
@@ -71,10 +71,8 @@ A sample configuration is given below.
1. Execute database scripts.
Execute the scripts in the `/dbscripts/db2.sql` file, against the database created.
-
-3. If you have a requirement in using workflow feature, follow [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds).
-4. Download the DB2 JDBC driver for the version, you are using and copy it to the `/repository/components/lib` folder.
+3. Download the DB2 JDBC driver for the version, you are using and copy it to the `/repository/components/lib` folder.
---
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mssql.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mssql.md
index 248ab491f9..d33001f457 100644
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mssql.md
+++ b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mssql.md
@@ -84,11 +84,8 @@ A sample configuration is given below.
falsefalse
```
-
-3. If you have a requirement in using workflow feature follow,
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the MS SQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
+3. Download the MS SQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
---
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mysql.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mysql.md
index 478893a7f4..1a16b59618 100644
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mysql.md
+++ b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-mysql.md
@@ -96,10 +96,7 @@ A sample configuration is given below.
false
```
-3. If you have a requirement in using workflow feature follow,
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-
-4. Download the MySQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
+3. Download the MySQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
---
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md
index fe730967d1..8d2c3bef0b 100644
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md
+++ b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md
@@ -83,11 +83,8 @@ A sample configuration is given below.
2. Execute database scripts.
Execute the scripts in the `/dbscripts/oracle_rac.sql` file against the database created.
-
-3. If you have a requirement in using workflow feature follow,
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the Oracle RAC JDBC driver for the version, you are using and
+3. Download the Oracle RAC JDBC driver for the version, you are using and
copy it to the `/repository/components/lib` folder
---
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle.md
index 0bf6159d11..e9d2ffac6b 100644
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle.md
+++ b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-oracle.md
@@ -67,11 +67,8 @@ A sample configuration is given below.
Execute the scripts in the following file, against the database created.
- `/dbscripts/oracle.sql`
-
-3. If you have a requirement to use the workflow feature, see
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the Oracle JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
+3. Download the Oracle JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
---
diff --git a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md
index 0549f76118..c3279650df 100644
--- a/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md
+++ b/en/identity-server/7.0.0/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md
@@ -63,10 +63,8 @@ A sample configuration is given below.
2. Execute database scripts.
Execute the scripts in the `/dbscripts/postgresql.sql` file against the database created.
-
-3. If you have a requirement to use the workflow feature, see [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds).
-4. Download the Postgres JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
+3. Download the Postgres JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
---
diff --git a/en/identity-server/7.0.0/docs/deploy/deployment-guide.md b/en/identity-server/7.0.0/docs/deploy/deployment-guide.md
index 7abc918642..337cee0e3b 100644
--- a/en/identity-server/7.0.0/docs/deploy/deployment-guide.md
+++ b/en/identity-server/7.0.0/docs/deploy/deployment-guide.md
@@ -64,7 +64,7 @@ The above recommendations can change based on the expected concurrency and perfo
Java
-
Oracle JDK 1.8
+
Open JDK 11
Web browsers
diff --git a/en/identity-server/7.0.0/docs/deploy/environment-compatibility.md b/en/identity-server/7.0.0/docs/deploy/environment-compatibility.md
index 9b9e09cc34..0c86789cc7 100644
--- a/en/identity-server/7.0.0/docs/deploy/environment-compatibility.md
+++ b/en/identity-server/7.0.0/docs/deploy/environment-compatibility.md
@@ -75,4 +75,4 @@ Following is a list of web browsers tested with WSO2 Identity Server:
Following is a list of LDAPs tested with WSO2 Identity Server:
- Open LDAP 2.4.28
-- Microsoft Active Directory Windows 2012
+- Microsoft Active Directory Windows 2019
diff --git a/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md b/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md
index 76cfeeac24..c3515b70da 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/asymmetric-encryption/index.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/asymmetric-encryption.md" %}
+{% include "../../../../../../includes/deploy/security/asymmetric-encryption/index.md" %}
diff --git a/en/identity-server/7.0.0/docs/deploy/security/keystores/configure-keystores.md b/en/identity-server/7.0.0/docs/deploy/security/keystores/configure-keystores.md
index 6b4991a739..fdb4c07e91 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/keystores/configure-keystores.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/keystores/configure-keystores.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/configure-keystores.md" %}
\ No newline at end of file
+{% include "../../../../../../includes/deploy/security/keystores/configure-keystores.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/deploy/security/keystores/create-new-keystores.md b/en/identity-server/7.0.0/docs/deploy/security/keystores/create-new-keystores.md
index c598f55db7..642c43e47d 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/keystores/create-new-keystores.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/keystores/create-new-keystores.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/create-new-keystores.md" %}
+{% include "../../../../../../includes/deploy/security/keystores/create-new-keystores.md" %}
diff --git a/en/identity-server/7.0.0/docs/deploy/security/keystores/index.md b/en/identity-server/7.0.0/docs/deploy/security/keystores/index.md
index 0c124b4c79..03c5b76111 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/keystores/index.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/keystores/index.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/index.md" %}
+{% include "../../../../../../includes/deploy/security/keystores/index.md" %}
diff --git a/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md b/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
index 0e9f8753db..1b3e14c893 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md" %}
+{% include "../../../../../../includes/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md" %}
diff --git a/en/identity-server/7.0.0/docs/deploy/security/security-guidelines/product-level-security-guidelines.md b/en/identity-server/7.0.0/docs/deploy/security/security-guidelines/product-level-security-guidelines.md
index dc6b3c77a8..7145e680b2 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/security-guidelines/product-level-security-guidelines.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/security-guidelines/product-level-security-guidelines.md
@@ -227,7 +227,7 @@ Log forging can be prevented by appending a UUID to the log message.
## JVM parameters
-- The recommended JDK versions are JDK 1.8 and 11. For more information, see Prerequisites.
+- The recommended JDK versions are JDK 11 and 17. For more information, see Prerequisites.
```java
-Xms512m -Xmx2048m
diff --git a/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md b/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
index 3bbdfe34c3..e4488efe7c 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
@@ -1,250 +1 @@
-# Blue-Green Data Encryption Key Rotation
-
-This section contains the complete process you need to follow in order to perform symmetric data encryption key rotation in WSO2 Identity Sever(WSO2 IS version 5.11.0 and above).
-
-Key rotation can be defined as retiring an encryption key and replacing it with a new key. Data is encrypted using a key known as a Data Encryption Key(DEK) and the DEK is then encrypted with another key called Key Encryption Key(KEK). This is known as envelope encryption. Frequent rotations of these encryption keys are considered as an industry best practice by PCI DSS and NIST standards.
-
-## Why should you rotate encryption keys?
-
-!!! info
- Originator Usage Period (OUP) is the time period during which encryption is applied to data.
-
-- A cryptoperiod is the time span during which a specific key is authorized for use. [NIST SP 800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf){:target="_blank"} recommends different cryptoperiods for different encryption key types.
-
- - Symmetric Data Encryption Keys
-
- - OUP recommended for large volumes of data is about a day or a week.
- - OUP recommended for smaller volumes of data is about 2 years.
-
- - Symmetric Key, Wrapping Keys
-
- - OUP recommended for a key that wraps a large number of keys is about a day or a week.
- - OUP recommended for a key that wraps a smaller number of keys is up to 2 years.
-
-- Security compliance requirements
-- Security breach requirements
-
-!!! note
- The above-mentioned cryptoperiods can vary based on other factors like the sensitivity of data and the amount of data we have.
-
-## Background
-
-WSO2 Identity Server has the following key usages for signing/encrypting data and each of these types will have different key rotation requirements.
-
-- TLS Connection
-- Signing and encryption of data (JWT assertions, payloads) shared with external parties (SP, IdP).
-- Encryption of sensitive runtime level configuration secrets/user data persisted in datastores and user stores.
-- Encryption of sensitive deployment-level configuration data in configuration files.
-
-From WSO2 IS 5.11.0 onwards, symmetric encryption is used to encrypt the internal sensitive runtime data above. The DEK used to encrypt these data is configured in the `deployment.toml` file and it is protected by a KEK. The secure vault is utilized as of now to protect this DEK. Here, only the rotation of the Data Encryption Key configured in the `deployment.toml` file is considered.
-
-## DEK rotation frequency
-
-In the case of a security compliance requirement, we can see that symmetric DEK rotation can be done in 2 years or less based on the volume of data present.
-
-In a security breach scenario, we must rotate the DEK immediately and re-encrypt all the data to the new DEK.
-
-## Key Rotation Approach
-
-WSO2 IS has introduced an external tool that re-encrypts internal data after rotation of the configured symmetric data encryption key. Here, the re-encryption of the identity and registry databases and some configuration files is considered. Apart from that, the tool syncs end-user data that gets generated in the live system to the new setup.
-
-The external Java client that performs the above tasks can be created by following the steps [here](#how-to-create-the-key-rotation-tool).
-
-## Tables that support re-encryption
-
-At the moment, the tables given below are supported for re-encryption.
-
-| **Table** | **Fields** |
-|-----------|---------------|
-| IDN_IDENTITY_USER_DATA | TOTP secretKey and verifiedSecretKey claims |
-| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth2 authorization codes |
-| IDN_OAUTH2_ACCESS_TOKEN | OAuth2 access and refresh tokens |
-| IDN_OAUTH_CONSUMER_APPS | Consumer secrets
-| WF_BPS_PROFILE | BPS profile password |
-| WF_REQUEST | WF request credentials |
-| REG_PROPERTY | Keystore passwords, Keystore privatekeyPass, and Entitlement subscriberPasswords |
-
-## Configuration files that support re-encryption
-
-At the moment, the configuration files given below are supported for re-encryption.
-
-| **Configuration file** | **Path** | **Property** |
-|---------------------------|-----------|--------------|
-| Event publishers | `/repository/deployment/server/eventpublishers` files | Password |
-| Super tenant secondary user stores | `/repository/deployment/server/userstores/` files | Password |
-| Tenant secondary userstores | `/repository/tenants//userstores/` files | Password |
-
-## Tables that support syncing
-
-At the moment, the tables given below can be synced during key rotation from the old setup to the new setup. Any other data will not be persisted in the new setup.
-
-| **Table** | **Purpose** | **Recommendation** |
-|-----------|---------------|-----------------------|
-| IDN_IDENTITY_USER_DATA | Identity claims when the identity data store is enabled | Usually recommended to sync if identity management features are enabled in the system |
-| IDN_OAUTH2_ACCESS_TOKEN | OAuth 2.0 tokens | Need to sync if the tokens created during the key rotation period need to be valid after key rotation |
-| IDN_OAUTH2_ACCESS_TOKEN_SCOPE | OAuth 2.0 scopes | If the IDN_OAUTH2_ACCESS_TOKEN is synced, this table also needs to be synced |
-| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth 2.0 authorization codes | Need to sync if the authorization codes created during the key rotation period need to be valid after key rotation |
-
-## How To Create The Key Rotation Tool
-
-!!! note
- In this section, `` is the directory where the current Identity Server resides, and `` is the directory where the copy of the current Identity Server resides. `` refers to the location [here](https://github.com/wso2/identity-tools/components/org.wso2.carbon.identity.keyrotation){:target="_blank"} and the `` refers to the location of the external tool.
-
-1. Clone the repository, [identity-tools](https://github.com/wso2/identity-tools){:target="_blank"}.
-
-2. Build it using maven by running the command `mvn clean install`.
-
-3. Go to the `/target` folder and copy the `keyrotation-tool--SNAPSHOT.jar` file and the `/target/lib` folder to ``. Get the `properties.yaml` file, `keyrotation.sh` file, and the `triggers` folder from `/src/main/resources` and copy them to the same `` location.
-
-## Performing blue-green key rotation
-
-1. Block all privileged user flows and allow only end-user flows.
-
- !!! note
- For the privileged user flows, block all admin services from the load balancer and the management console as well. For end user flows, the above [tables]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation/#tables-that-support-re-encryption) will be synced to the ``, so only these end user data flows should be allowed to generate in ``.
-
-2. Execute the `old.sql` script in the `` identity database to create temp tables and triggers. The triggers can be found inside the `/triggers` folder.
-
-3. Create a copy of the ``(This copied directory will be referred to as the `NEW_IS_HOME`) and dump `` identity and registry databases and create the new databases.
-
-4. Drop the temp tables and triggers in the `` identity database using the `new.sql` script. The triggers can be found inside the `/triggers` folder.
-
-5. Open the `properties.yaml` file in `` and edit the configurations accordingly.
-
- - oldSecretKey - The symmetric encryption key used in the ``.
-
- !!! note
- If the key is encrypted using cipher tool, decrypt it back as shown [here](https://shagihan.medium.com/decrypt-encrypted-text-with-the-wso2-cipher-tool-15b67624620a){:target="_blank"}.
-
- - newSecretKey - The new symmetric encryption key.
-
- !!! tip
- Generate using a tool like openssl using the command, `openssl rand -hex 16`.
-
- - newISHome - The absolute path of the ``.
- - oldIdnDBUrl - `` identity database URL.
- - oldIdnUsername - `` identity database username.
- - oldIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
- - newIdnDBUrl - `` identity database URL.
- - newIdnUsername - `` identity database username.
- - newIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
- - newRegDBUrl - `` registry database URL.
- - newRegUsername - `` registry database username.
- - newRegPassword - `` registry database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
- - enableDBMigrator - Enable/disable re-encryption for the identity and registry databases.
-
- !!! note
- Keep this always **true** to avoid unnecessary issues.
-
- - enableConfigMigrator - Enable/disable re-encryption for the configuration files.
-
- !!! note
- Keep this always **true** to avoid unnecessary issues.
-
- - enableSyncMigrator - Enable/disable syncing mechanism.
-
- !!! note
- You only need to set this to **true**, if you have opted in for blue-green key rotation with zero downtime for the end user flows.
-
- - chunkSize - Size of the record chunks being retrieved from the database tables for syncing.
-
- ??? tip "Sample configuration written for the properties.yaml file"
-
- ```
- oldSecretKey: AFA27B44D43B02A9FEA41D13CEDC2E40
- newSecretKey: 1fc0bc7a3805b42afa5f5af07a595f56
- newISHome: /home/IS/wso2is-5.12.0
- oldIdnDBUrl: jdbc:mysql://localhost:3306/regdb?useSSL=false
- oldIdnUsername: root
- oldIdnPassword: cm9vdA==
- newIdnDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false
- newIdnUsername: root
- newIdnPassword: cm9vdA==
- newRegDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false
- newRegUsername: root
- newRegPassword: cm9vdA==
- enableDBMigrator: true
- enableConfigMigrator: true
- enableSyncMigrator: true
- chunkSize: 2
- ```
-
- ??? tip "Sample configurations written for DB type URL"
- **H2 DB**
- ```
- jdbc:h2:~/Desktop/IS/copy/wso2is-5.11.0-beta5-SNAPSHOT/repository/database/WSO2IDENTITY_DB
- ```
- **MySQL**
- ```
- jdbc:mysql://localhost:3306/idndb?useSSL=false
- ```
- **DB2**
- ```
- jdbc:db2://localhost:50000/idndb
- ```
- **PostgreSQL**
- ```
- jdbc:postgresql://localhost:5432/idndb
- ```
- **MSSQL**
- ```
- jdbc:sqlserver://localhost:1433;databaseName=idndb
- ```
- **Oracle DB**
- ```
- jdbc:oracle:thin:@localhost:1521/ORCLCDB.LOCALDOMAIN
- ```
-
-6. Run the tool using the `./keyrotation.sh keyrotation-tool--SNAPSHOT.jar` command from ``.
-
-7. Edit the `` `deployment.toml` file having the new configured databases and the new key.
-
-8. Start `` once the re-encryption for the existing DB and config file is done.
-
-9. When no new entries are being synced in the logs, route traffic to `` and enable all load balancer API endpoints(privileged and end-user flows).
-
-!!! note "Important"
- Do not stop the tool at once, let it sync any remaining data in the temp tables after routing the traffic.
-
-## Verifying the key rotation
-
-- Check the log files to verify if re-encryption happened successfully for the 7 identity and registry database tables. Check the logs given below for the successful/failed re-encryption counts of OAuth2 access and refresh tokens.
-
- ??? tip "DB log sample"
- ```
- Successfully updated OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 897
- Failed OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 0
- ```
-
- !!! note
- If the key rotation task is successful, the failed logs count should be `0` for all the tables.
-
-- Check the log files to verify if re-encryption happened successfully for the 3 configuration files. Check the logs given below for the successful/failed re-encryption counts of event publisher configuration files.
-
- ??? tip "Config file log sample"
- ```
- Updated event publisher configuration files: 8
- Failed event publisher configuration files: 0
- ```
-
- !!! note
- If the key rotation task is successful, the failed logs count should be `0` for all the configuration files.
-
-- Check the log files to verify if the transformation of the synced data happened successfully for the 4 tables. Check the logs given below for the successful/failed transformation counts of `IDN_IDENTITY_USER_DATA` table.
-
- ??? tip "Synced log sample"
- ```
- Successfully transformed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 2
- Transformation failed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 0
- ```
-
- !!! note
- If the synced task is successful, the failed logs count should be `0` for all the synced tables.
-
-- Check for any errors in the log files and carefully analyze the logs if the error can be ignored and other steps can be proceeded with. Otherwise, check what has caused the error.
-
-## Recovering from any failure
-
-If the key rotation task stops midway, follow the blue green key rotation user guide steps again.
-
-If there are errors logged in the log files, carefully go through the errors and find what has caused the error.
+{% include "../../../../../../includes/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/index.md b/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/index.md
index d72560d24d..a681399587 100644
--- a/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/index.md
+++ b/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/index.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/symmetric-encryption.md" %}
+{% include "../../../../../../includes/deploy/security/symmetric-encryption/index.md" %}
diff --git a/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/use-symmetric-encryption.md b/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/use-symmetric-encryption.md
deleted file mode 100644
index ecfc8bb36c..0000000000
--- a/en/identity-server/7.0.0/docs/deploy/security/symmetric-encryption/use-symmetric-encryption.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# Configure symmetric key encryption
-
-This section explains the configurations related to [symmetric key encryption]({{base_path}}/deploy/security/symmetric-encryption).
-
-WSO2 Identity Server uses symmetric encryption by default for encrypting the following data:
-
-- Event publisher passwords
-- Secondary user store properties
-- TOTP `secretKey` and `verifiedSecretKey` claims
-- OAuth 2.0 authorization codes, access tokens, refresh tokens, and consumer secrets (only when encryption enabled)
-
- !!! note
-
- To enable encryption of OAuth 2.0 authorization codes, access tokens, refresh tokens, and consumer secrets, add the following configuration to the `deployment.toml` found in the `/repository/conf/` directory.
- ```toml
- [oauth.extensions]
- token_persistence_processor = "org.wso2.carbon.identity.oauth.tokenprocessor.EncryptionDecryptionPersistenceProcessor"
- ```
-
-- Secondary keystore passwords, and private-key passwords
-- BPS profile passwords
-- Workflow request credentials
-
-For other types of encryption, [asymmetric encryption]({{base_path}}/deploy/security/asymmetric-encryption) is used by default.
-
-
-!!! warning
- All configuration changes should be applied before starting Identity Server for the first time. Otherwise, a [key rotation]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation) will be required.
-
-## Configure a secret key
-
-For enhanced security, it is recommended to generate your own secret key for symmetric key encryption in {{product_name}}. To do so,
-
-1. Generate a unique 128-bit secret key. If you use OpenSSL, the command will be as follows:
-
- ```bash
- openssl rand -hex 16
- ```
-
-2. Add your generated key to the `deployment.toml` found in the `/repository/conf/` directory as follows:
-
- ```toml
- [encryption]
- key = "03BAFEB27A8E871CAD83C5CD4E771DAB"
- ```
-
-If a custom encryption key is not provided, the value of `encryption.key` in this configuration file will be used as the default key.
-
-## Algorithm used
-
-`AES/GCM/NoPadding` is used as the symmetric key encryption algorithm.
-
-GCM is a stream cipher. Hence, there is a performance advantage of using it due to the parallel encryption of each block. There is no need to use a padding mechanism in GCM mode. In GCM mode, the initialization vector (IV) should be a unique value for each encryption request. The corresponding IVs of each unique value should be kept track of in order to decrypt this internal data. The keysize supported is AES-128.
-
-## Internal crypto provider
-
-The `org.wso2.carbon.crypto.provider.SymmetricKeyInternalCryptoProvider` provider is used as the internal crypto provider. When configuring the `SymmetricKeyInternalCryptoProvider`, the secret key value needs to be provided in the configuration as well.
-
-The following configuration is enabled by default in the `/repository/resources/conf/default.json` file to use the above-mentioned internal crypto provider.
-
-```json
-"encryption.internal_crypto_provider": "org.wso2.carbon.crypto.provider.SymmetricKeyInternalCryptoProvider"
-```
-
-## Encrypting symmetric encryption key with cipher tool
-
-It is advised to encrypt the symmetric encryption key with a cipher tool as mentioned [here]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool).
diff --git a/en/identity-server/7.0.0/docs/get-started/try-samples/ws-federation-webapp.md b/en/identity-server/7.0.0/docs/get-started/try-samples/ws-federation-webapp.md
index 593b92deee..18295a2669 100644
--- a/en/identity-server/7.0.0/docs/get-started/try-samples/ws-federation-webapp.md
+++ b/en/identity-server/7.0.0/docs/get-started/try-samples/ws-federation-webapp.md
@@ -107,14 +107,14 @@ To configure additional properties for the sample application:
6. Click **Update** to save your configurations.
!!! tip
- Currently, the signing algorithm used for WS-Federation by default is `rsa-sha1`, and the digest algorithm used is `sha1`.
+ Currently, the signing algorithm used for WS-Federation by default is `rsa-sha256`, and the digest algorithm used is `sha256`.
To change the default algorithms, add the following configuration in the `deployment.toml` file found in the `/repository/conf` directory.
- The example given below sets the signing algorithm to `rsa-sha256` and the digest algorithm to `sha256`.
+ The example given below sets the signing algorithm to `rsa-sha1` and the digest algorithm to `sha1`.
```toml
[sts]
- signature_algorithm = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
- digest_algorithm = "http://www.w3.org/2001/04/xmlenc#sha256"
+ signature_algorithm = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha1"
+ digest_algorithm = "http://www.w3.org/2001/04/xmlenc#sha1"
```
## Try it out
diff --git a/en/identity-server/7.0.0/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md b/en/identity-server/7.0.0/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md
index 9bddebbacb..119e8c9aa9 100644
--- a/en/identity-server/7.0.0/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md
+++ b/en/identity-server/7.0.0/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md
@@ -7,10 +7,10 @@ Allow administrator to invite users to set their own passwords during the onboar
For inviting users to set their password, follow these instructions:
1. On the {{product_name}} Console, go to **Login & Registration** > **User Onboarding** > **Invite User to Set Password**.
-2. Check the **Enable user email verification** if a verification step is required during user creation.
-3. Select the **Enable account lock on creation** to lock the user account during creation.
-4. If you want to send an account activation email, make sure the corresponding option is enabled.
-5. Set the **Email verification code expiry time** and **Ask password code expiry time** to define how long the codes should be valid.
+2. Check the **Enable email invitations for user password setup** to send an email to the user to set the password after user creation.
+3. Select the **Enable account lock on creation** to lock the user account during user creation.
+4. If you want to send an account activation confirmation email, enable the **Send account activation email**.
+5. Set the **Password setup invitation code expiration time** in minutes to define how long the password setup invitation e-mail would be valid. For infinite validity period, set -1. Setting 0 will cause immediate expiry of the invitation.
6. Click **Update** to save the changes.
![Invite User to Set Password Configuration]({{base_path}}/assets/img/guides/account-configurations/invite-user-to-set-password.png){: width="700" style="display: block; margin: 0;"}
diff --git a/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md b/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md
deleted file mode 100644
index 8a6e3e98eb..0000000000
--- a/en/identity-server/7.0.0/docs/guides/authorization/impersonation/user-impersonation.md
+++ /dev/null
@@ -1,4 +0,0 @@
-{% set base_url = "localhost:9443" %}
-{% set base_url_sample = "localhost:9443" %}
-
-{% include "../../../../../../includes/guides/authorization/user-impersonation.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/guides/authorization/index.md b/en/identity-server/7.0.0/docs/guides/authorization/index.md
index bdc01e381e..9753b1c40a 100644
--- a/en/identity-server/7.0.0/docs/guides/authorization/index.md
+++ b/en/identity-server/7.0.0/docs/guides/authorization/index.md
@@ -1,16 +1 @@
-# Authorization
-
-The authorization guide offers detailed instructions for implementing a range of authorization scenarios within your application using {{ product_name }}, ensuring secure access and enhanced protection.
-
-## API authorization
-
-- [Role-based access control (RBAC)]({{base_path}}/guides/authorization/api-authorization/api-authorization/)
-- [Attribute-based access control (ABAC)]({{base_path}}/guides/authorization/api-authorization/attribute-based-access-control/)
-
-## Fine-grained authorization
-
-- [Fine-grained authorization]({{base_path}}/guides/authorization/fine-grained-authorization/rule-based-provisioning/)
-
-## Impersonation
-
-- [Impersonation]({{base_path}}/guides/authorization/impersonation/user-impersonation/)
\ No newline at end of file
+{% include "../../../../../includes/guides/authorization/index.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/guides/authorization/user-impersonation.md b/en/identity-server/7.0.0/docs/guides/authorization/user-impersonation.md
new file mode 100644
index 0000000000..397e07d676
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/guides/authorization/user-impersonation.md
@@ -0,0 +1,4 @@
+{% set base_url = "localhost:9443" %}
+{% set base_url_sample = "localhost:9443" %}
+
+{% include "../../../../../includes/guides/authorization/user-impersonation.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/guides/branding/add-custom-layouts.md b/en/identity-server/7.0.0/docs/guides/branding/add-custom-layouts.md
new file mode 100644
index 0000000000..8554c1e5c6
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/guides/branding/add-custom-layouts.md
@@ -0,0 +1 @@
+{% include "../../../../../includes/guides/branding/add-custom-layouts.md" %}
\ No newline at end of file
diff --git a/en/identity-server/7.0.0/docs/quick-starts/angular.md b/en/identity-server/7.0.0/docs/quick-starts/angular.md
new file mode 100644
index 0000000000..6b26c8b43a
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/quick-starts/angular.md
@@ -0,0 +1,263 @@
+---
+template: templates/quick-start.html
+heading: Angular Quickstart
+description: Welcome to the Angular Quickstart guide! In this document, you will learn to build a Angular app, add user login and display user profile information using WSO2 Identity Server.
+what_you_will_learn:
+ - Create new Angular app
+ - Install angular-oauth2-oidc package
+ - Add user login and logout
+ - Display user profile information
+prerequisites:
+ - About 15 minutes
+ - Set-up WSO2 Identity Server
+ - Install a JS package manager
+ - Install Angular CLI
+ - A favorite text editor or IDE
+source_code: Angular App Sample
+
+whats_next:
+# - Try out {{ product_name }} complete React guide
+# - Try out {{product_name}} user onboarding complete guide for React
+# - Read security best practices for React app guide
+---
+## Configure an Application in {{ product_name }}
+
+- Sign into {{ product_name }} console and navigate to **Applications > New Application.**
+- Select **Single Page Application** and complete the wizard popup by providing a suitable name and an authorized redirect URL
+
+*Example:*
+
+- *Name - wso2is-angular*
+- *Authorized redirect URL - http://localhost:4200*
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use`http://localhost:4200`, as the sample app will be accessible at this URL.
+
+!!! note
+
+ Make a note of the following values from the **Protocol** and **Info** tabs of the registered application. You will need them during the **Step 4**
+
+ - **`client-id`** from the **Protocol** tab.
+ - **`issuer`** from from the **Info** tab.
+
+## Create an Angular app
+
+Create an Angular app using Angular CLI.
+
+
+
+
+``` bash
+
+ ng new wso2is-angular
+```
+
+!!! tip "Tip"
+ To run the command above, you need to have Angular CLI installed. You can install it using the following command.
+ === "npm"
+
+ ``` bash
+
+ npm install -g @angular/cli@17
+
+ ```
+ === "yarn"
+
+ ``` bash
+
+ yarn global add @angular/cli@17
+
+ ```
+
+ === "pnpm"
+
+ ``` bash
+
+ pnpm add -g @angular/cli@17
+
+ ```
+
+
+
+## Install angular-oauth2-oidc
+
+The [Angular OAuth2 OIDC SDK](https://www.npmjs.com/package/angular-oauth2-oidc){:target="_blank"} is a production-ready OIDC SDK that simplifies integrating {{product_name}} into your Angular applications. To get started, simply add the Angular OAuth2 OIDC SDK to the project. Make sure to stop the dev server started in the previous step.
+
+=== "npm"
+
+ ``` bash
+
+ npm install angular-oauth2-oidc
+
+ ```
+
+=== "yarn"
+
+ ``` bash
+
+ yarn add angular-oauth2-oidc
+
+ ```
+
+=== "pnpm"
+
+ ``` bash
+
+ pnpm add angular-oauth2-oidc
+
+ ```
+
+
+
+
+
+## Configure `AuthConfig` in your app
+
+The `AuthConfig` object holds the configuration necessary for connecting your app to {{product_name}}.
+
+Replace the content of `app.config.ts` file with the following code.
+
+!!! Important
+
+ Make sure to replace the placeholders in the following code with the **`client-id`** and **`issuer`** values you copied in **Step-1** during the application registration in the {{product_name}} console.
+
+ - ``
+ - ``
+
+```javascript title="app.config.ts"
+
+import { ApplicationConfig, APP_INITIALIZER } from '@angular/core';
+import { provideRouter } from '@angular/router';
+import { provideHttpClient } from '@angular/common/http';
+import { provideOAuthClient, OAuthService, AuthConfig } from 'angular-oauth2-oidc';
+import { routes } from './app.routes';
+
+export const authConfig: AuthConfig = {
+ issuer: '',
+ redirectUri: 'http://localhost:4200',
+ clientId: '',
+ responseType: 'code',
+ scope: 'openid profile email internal_login',
+ strictDiscoveryDocumentValidation: false,
+};
+
+function initializeOAuth(oauthService: OAuthService): () => Promise {
+ return () => {
+ oauthService.configure(authConfig);
+ return oauthService.loadDiscoveryDocumentAndTryLogin().then(() => { });
+ };
+}
+
+export const appConfig: ApplicationConfig = {
+ providers: [provideRouter(routes),
+ provideHttpClient(),
+ provideOAuthClient(),
+ {
+ provide: APP_INITIALIZER,
+ useFactory: initializeOAuth,
+ deps: [OAuthService],
+ multi: true
+ }
+ ]
+};
+
+
+```
+
+!!! Important
+
+ Make sure to add `strictDiscoveryDocumentValidation: false` parameter.
+
+## Add login and logout link to your app
+
+Angular uses services to access authentication data, and you can inject the `OAuthService` into your components to manage user authentication.
+
+The `OAuthService` provides methods for logging in and out, checking the authentication status, and retrieving access tokens.
+
+Replace the existing content of the `app.component.ts` file with following content.
+
+```javascript title="app.component.ts" hl_lines="16-28"
+
+import { Component } from '@angular/core';
+import { RouterOutlet } from '@angular/router';
+import { OAuthService } from 'angular-oauth2-oidc';
+import { CommonModule } from '@angular/common';
+
+@Component({
+ selector: 'app-root',
+ standalone: true,
+ imports: [RouterOutlet, CommonModule],
+ templateUrl: './app.component.html',
+ styleUrl: './app.component.css'
+})
+
+export class AppComponent {
+ title = 'wso2is-angular';
+ isAuthorized = this.oAuthService.hasValidAccessToken();
+
+ constructor(private oAuthService: OAuthService) {
+
+ }
+
+ login() {
+ this.oAuthService.initLoginFlow();
+ }
+
+ logout() {
+ this.oAuthService.revokeTokenAndLogout();
+ }
+}
+
+```
+
+Next, replace the existing content of the `app.component.html` file with following content to add login and logout URLs.
+
+```html title="app.component.html"
+
+
+
+
+
+```
+
+
+
+
+
+Visit your app's homepage at [http://localhost:4200](http://localhost:4200).
+
+!!! Important
+
+ You need to create a test user in {{ product_name }} by following this [guide]({{ base_path }}/guides/users/manage-users/#onboard-single-user){:target="_blank"} to tryout login and logout features.
+
+## Display logged in user details
+
+Modified the code as below to see logged in user details.
+
+
+Add the `username()` function to the `app.component.ts` file to access the username attribute.
+
+```javascript title="app.component.ts" hl_lines="3-6"
+...
+
+ get username() {
+ var claims = this.oAuthService.getIdentityClaims();
+ if (!claims) return null;
+ return claims['username'];
+ }
+
+...
+```
+
+Modify the `app.component.html` file with the following code.
+
+```html title="app.component.html" hl_lines="2"
+
+
+
Hello {{ username }}!
+
+
+```
+
+
diff --git a/en/identity-server/7.0.0/docs/quick-starts/nextjs.md b/en/identity-server/7.0.0/docs/quick-starts/nextjs.md
new file mode 100644
index 0000000000..37bf11860d
--- /dev/null
+++ b/en/identity-server/7.0.0/docs/quick-starts/nextjs.md
@@ -0,0 +1,320 @@
+---
+template: templates/quick-start.html
+heading: Next.JS Quickstart
+description: Welcome to the Next.js Quickstart guide! In this document, you will learn to build a Next.js app, add user login and display user profile information using WSO2 Identity Server.
+what_you_will_learn:
+ - Create new Next.js app
+ - Install Asgardeo provider for Auth.js
+ - Add user login and logout
+ - Display user profile information
+prerequisites:
+ - About 15 minutes
+ - Set-up WSO2 Identity Server
+ - Install a JS package manager
+ - A favorite text editor or IDE
+# source_code: Next.js App Sample
+whats_next:
+ # - Try out {{ product_name }} complete React guide
+ # - Try out {{product_name}} user onboarding complete guide for React
+ # - Read security best practices for React app guide
+---
+
+
+## Configure an Application in {{ product_name }}
+
+- Sign into {{ product_name }} console and navigate to **Applications > New Application.**
+- Select **Traditional Web Application** and complete the wizard popup by providing a suitable name and an authorized redirect URL.(*Ensure that the protocol remains set to OpenID Connect (OIDC).)*
+
+*Example:*
+
+- *Name - wso2is-nextjs*
+- *Authorized redirect URL - http://localhost:3000/api/auth/callback/asgardeo*
+
+
+
+!!! Info
+
+ The authorized redirect URL determines where {{product_name}} should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use ` http://localhost:3000/api/auth/callback/asgardeo`, as the authorized redirect URL .
+
+!!! note
+
+ Make a note of the following values from the **Protocol** and **Info** tabs of the registered application. You will need them during the **Step 4**
+
+ - **`client-id`** from the **Protocol** tab.
+ - **`client-secret`** from the **Protocol** tab.
+ - **`issuer`** from from the **Info** tab.
+
+## Create a Next.js app
+
+Create your new Next.js app.
+
+=== "npm"
+
+ ``` bash
+ npx create-next-app@latest --typescript wso2is-nextjs
+
+ cd wso2is-nextjs
+
+ npm install
+
+ npm run dev
+ ```
+
+=== "yarn"
+
+ ``` bash
+ yarn create next-app --typescript wso2is-nextjs
+
+ cd wso2is-nextjs
+
+ yarn install
+
+ yarn dev
+ ```
+
+=== "pnpm"
+
+ ``` bash
+ pnpm create next-app --typescript wso2is-nextjs
+
+ cd wso2is-nextjs
+
+ pnpm install
+
+ pnpm run dev
+ ```
+
+## Install Auth.js library
+
+Auth.js is a lightweight JavaScript library designed for simplifying authentication workflows in web application. The [Asgardeo provider for Auth.js](https://authjs.dev/reference/core/providers/asgardeo){:target="_blank"} offers all the components and hooks you need to integrate your app with {{product_name}}.To get started, simply add Auth.js library to the project. Make sure to stop the dev server started in the previous step.
+
+
+!!! Info
+
+ Asgardeo-branded SDKs and such as Asgardeo provider for Auth.js used in this guide can be used to build apps to work with the all [WSO2 identity suite](https://wso2.com/identity-and-access-management/){:target="_blank"} of products that includes [WSO2 Identity Server (WSO2 IS)](https://wso2.com/identity-server/){:target="_blank"}, WSO2 [Private Identity Cloud (WSO2 PIC)](https://wso2.com/private-identity-cloud/){:target="_blank"} and [Asgardeo](https://wso2.com/asgardeo/){:target="_blank"}.
+
+
+=== "npm"
+
+ ``` bash
+ npm install next-auth@beta
+ ```
+
+=== "yarn"
+
+ ``` bash
+ yarn add next-auth@beta
+ ```
+
+=== "pnpm"
+
+ ``` bash
+ pnpm add next-auth@beta
+ ```
+
+Next, generate **`AUTH_SECRET`** environment variable.
+
+=== "npm"
+
+ ``` bash
+ npx auth secret
+
+ ```
+=== "yarn"
+
+ ``` bash
+ yarn dlx auth secret
+ ```
+
+=== "pnpm"
+
+ ``` bash
+ pnpm dlx auth secret
+ ```
+
+Add following entries to the .env or .env.local file, and make sure to replace the placeholders in the following code with the **`client-id`**, **`client-secret`** and **`issuer`** values you copied in **Step-1** during the application registration in the {{product_name}} console.
+
+
+```bash title=".env.local"
+ AUTH_ASGARDEO_ID=""
+ AUTH_ASGARDEO_SECRET=""
+ AUTH_ASGARDEO_ISSUER=""
+
+```
+
+
+
+## Create the `auth.js` configuration File
+
+Create a file called `/src/auth.ts'`.
+
+```bash
+
+touch /src/auth.ts
+
+```
+
+Add {{product_name}} as a provider in the `/src/auth.ts'` file.
+
+```javascript title="auth.ts"
+import NextAuth from "next-auth"
+import Asgardeo from "next-auth/providers/asgardeo"
+
+export const { handlers, signIn, signOut, auth } = NextAuth({
+ providers: [Asgardeo({
+ issuer: process.env.AUTH_ASGARDEO_ISSUER
+ })],
+})
+
+```
+
+
+
+Create a Route Handler file in the `src/app/api/auth/[...nextauth]/route.ts` location.
+
+```bash
+mkdir -p src/app/api/auth/\[...nextauth\]
+
+touch mkdir -p src/app/api/auth/\[...nextauth\]/route.ts
+
+```
+
+!!! Note
+ The directory `src/app/api/auth/[...nextauth]/route.ts` in a Next.js project is used to define a dynamic API route for handling authentication. The `[...nextauth]` is a catch-all route that processes multiple authentication-related requests such as sign-in, sign-out, and session management. The route.ts file specifies the logic for these operations, typically by exporting handlers for HTTP methods like GET and POST. This setup centralizes authentication logic, supports OAuth providers like Google or GitHub, and integrates seamlessly into Next.js applications for secure and scalable authentication workflows.
+
+
+Update the `src/app/api/auth/[...nextauth]/route.ts` file with the following code.
+
+```javascript title="route.ts"
+import { handlers } from "@/auth"
+export const { GET, POST } = handlers
+```
+
+
+Next, create `src/middleware.ts` file with the following code.
+
+```bash
+
+touch mkdir -p src/middleware.ts
+
+```
+
+
+```javascript title="middleware.ts"
+export { auth as middleware } from "@/auth"
+
+```
+
+
+## Add login and logout link to your app
+
+Replace the existing content of the `page.tsx` file with following content to add login and logout features from Auth.JS.
+
+```javascript title="page.tsx"
+import { auth, signIn, signOut } from "@/auth"
+
+export default async function Home() {
+ const session = await auth();
+
+ return (
+
+ {
+ !session ? (
+
+ ) : (
+ <>
+
You are now signed in!
+
+
+ >
+ )
+ }
+
+ );
+}
+```
+
+Visit your app's homepage at [http://localhost:3000](http://localhost:3000).
+
+!!! Important
+
+ You need to create a test user in {{ product_name }} by following this [guide]({{ base_path }}/guides/users/manage-users/#onboard-single-user){:target="_blank"} to tryout login and logout features.
+
+## Display logged in user details
+
+Modified the code as below to see logged in user details.
+
+```javascript title="auth.ts" hl_lines="14-29"
+
+import NextAuth from "next-auth"
+import Asgardeo from "next-auth/providers/asgardeo"
+
+declare module "next-auth" {
+ interface User {
+ username?: string;
+ }
+}
+
+export const { handlers, signIn, signOut, auth } = NextAuth({
+ providers: [Asgardeo({
+ issuer: process.env.AUTH_ASGARDEO_ISSUER
+ })],
+ callbacks: {
+ async jwt({ token, profile }) {
+ if (profile) {
+ token.username = profile.username;
+ }
+
+ return token;
+ },
+ async session({ session, token }) {
+ if (token) {
+ session.user.username = token.username as string;
+ }
+
+ return session;
+ }
+ }
+})
+
+```
+
+Then, update `page.tsx` with the following highlighted line to display the username of logged in user.
+
+```javascript title="page.tsx" hl_lines="4"
+
+...
+ <>
+
You are now signed in!
+
hello {session.user?.username}
+
+ >
+
+...
+
+```
+
+
+
+
diff --git a/en/identity-server/7.0.0/docs/quick-starts/react.md b/en/identity-server/7.0.0/docs/quick-starts/react.md
index 045fdf59de..0bdc5cdf45 100644
--- a/en/identity-server/7.0.0/docs/quick-starts/react.md
+++ b/en/identity-server/7.0.0/docs/quick-starts/react.md
@@ -9,32 +9,32 @@ what_you_will_learn:
- Display user profile information
prerequisites:
- About 15 minutes
- - Set-up WSO2 Identity Server
+ - Set-up WSO2 Identity Server
- Install a JS package manager
- A favorite text editor or IDE
source_code: React Vite App Sample
whats_next:
- - Try out complete React guide
- - Try out user onboarding complete guide for React
+ - Try out {{ product_name }} complete React guide
+ - Try out {{product_name}} user onboarding complete guide for React
- Read security best practices for React app guide
---
-## Configure an Application in WSO2 Identity Server
+## Configure an Application in {{ product_name }}
-- Sign into WSO2 Identity Server console and navigate to Applications > New Application.
+- Sign into {{ product_name }} console and navigate to Applications > New Application.
- Select Single Page Application and complete the wizard popup by providing a suitable name and an authorized redirect URL
- Name - IS-React
- Authorized redirect URL - `http://localhost:5173`
-!!! abstract
+!!! Info
The authorized redirect URL determines where WSO2 Identity Server should send users after they successfully log in. Typically, this will be the web address where your app is hosted. For this guide, we'll use`http://localhost:5173`, as the sample app will be accessible at this URL.
!!! note
- Note down the following values : you will need them during the**Step 4**
+ Note down the following values : you will need them during the **Step 4**
- -`client-id`
+ - `client-id`
- `base-url`
- `redirect-url`
@@ -80,22 +80,28 @@ Create (a.k.a scaffold) your new React app using Vite.
## Install @asgardeo/auth-react
-Asgardeo React SDK provides all the components and hooks you need to integrate Asgardeo into your app. To get started, simply add the Asgardeo React SDK to the project.
+Asgardeo React SDK provides all the components and hooks you need to integrate Asgardeo into your app. To get started, simply add the Asgardeo React SDK to the project. Make sure to stop the dev server started in the previous step.
=== "npm"
- ``bash npm install @asgardeo/auth-react ``
+ ``` bash
+ npm install @asgardeo/auth-react
+ ```
=== "yarn"
- ``bash yarn add @asgardeo/auth-react ``
+ ``` bash
+ yarn add @asgardeo/auth-react
+ ```
=== "pnpm"
- ``bash pnpm add @asgardeo/auth-react ``
+ ``` bash
+ pnpm add @asgardeo/auth-react
+ ```
-!!! note
+!!! Info
Asgardeo-branded SDKs can be used to build apps to work with the all WSO2 identity suite of products that includes WSO2 Identity Server (WSO2 IS), WSO2 Private Identity Cloud (WSO2 PIC), and Asgardeo.
@@ -107,11 +113,11 @@ The `` serves as a context provider for user login in the app. Y
Add the following changes to the `main.jsx` file.
-!!! note
+!!! Important
Replace below placeholders with the generated`client-id` from the app you registered in WSO2 Identity Server.
- -``
+ - ``
```javascript
@@ -130,11 +136,11 @@ const config = {
}
ReactDOM.createRoot(document.getElementById('root')).render(
-
-
-
-
-,
+
+
+
+
+ ,
);
```
@@ -154,11 +160,11 @@ const { state, signIn, signOut } = useAuthContext();
return (
<>
- {
- state.isAuthenticated
- ?
- :
- }
+ {
+ state.isAuthenticated
+ ?
+ :
+ }
>
)
};
@@ -168,9 +174,9 @@ export default App;
Visit your app's homepage at [http://localhost:5173](http://localhost:5173).
-!!! tip
+!!! Important
- You need to create a test user in WSO2 Identity Server by following this guide to tryout login and logout features.
+ You need to create a test user in {{ product_name }} by following this [guide]({{ base_path }}/guides/users/manage-users/#onboard-single-user){:target="_blank"} to tryout login and logout features.
## Display logged in user details
@@ -184,14 +190,14 @@ const App = () => {
return (
<>
- {
- state.isAuthenticated ?
- <>
-
+
+ >
+ :
+ }
>
)
};
diff --git a/en/identity-server/7.0.0/mkdocs.yml b/en/identity-server/7.0.0/mkdocs.yml
index ad69e0b7a4..54606696b7 100644
--- a/en/identity-server/7.0.0/mkdocs.yml
+++ b/en/identity-server/7.0.0/mkdocs.yml
@@ -24,7 +24,12 @@ extra:
is_version: 7.0.0
plugins:
- - search
+ - search:
+ indexing: "full"
+ separator: "[^\\w._]+"
+ lang: ['en']
+ prebuild_index: true
+ ngram_length: 3
- markdownextradata: {}
- include-markdown
- redirects:
@@ -217,7 +222,6 @@ plugins:
'deploy/change-to-oracle-rac.md': 'deploy/configure/databases/carbon-database/change-to-oracle-rac.md'
'deploy/change-to-postgresql.md': 'deploy/configure/databases/carbon-database/change-to-postgresql.md'
'deploy/change-to-remote-h2.md': 'deploy/configure/databases/carbon-database/change-to-remote-h2.md'
- 'deploy/change-datasource-bpsds.md': 'deploy/configure/databases/carbon-database/change-datasource-bpsds.md'
'deploy/change-datasource-consent-management.md': 'deploy/configure/databases/carbon-database/change-datasource-consent-management.md'
'deploy/enable-fips-for-is.md': 'deploy/security/enable-fips-for-is.md'
@@ -328,6 +332,7 @@ plugins:
# To address the broken links in the API Authorization guides due to the directory structure mismatch is Asgardeo and IS
'guides/api-authorization.md': 'guides/authorization/api-authorization/api-authorization.md'
+ 'guides/authorization/impersonation/user-impersonation.md': 'guides/authorization/user-impersonation.md'
# Navigation
nav:
@@ -476,8 +481,7 @@ nav:
- Attribute-based access control: guides/authorization/api-authorization/attribute-based-access-control.md
- Fine-grained authorization:
- XACML in provisioning flows: guides/authorization/fine-grained-authorization/rule-based-provisioning.md
- - Impersonation:
- - User Impersonation: guides/authorization/impersonation/user-impersonation.md
+ - User Impersonation: guides/authorization/user-impersonation.md
- Branding:
- Branding: guides/branding/index.md
- Configure UI branding: guides/branding/configure-ui-branding.md
@@ -624,7 +628,6 @@ nav:
- Change to Oracle RAC: deploy/configure/databases/carbon-database/change-to-oracle-rac.md
- Change to PostgreSQL: deploy/configure/databases/carbon-database/change-to-postgresql.md
- Change to remote H2: deploy/configure/databases/carbon-database/change-to-remote-h2.md
- - Change the Default Datasource for BPS: deploy/configure/databases/carbon-database/change-datasource-bpsds.md
- Change the Default Datasource for Consent Management: deploy/configure/databases/carbon-database/change-datasource-consent-management.md
- Change the Default Datasource for Session Data: deploy/configure/databases/carbon-database/change-datasource-session.md
- Data Purging: deploy/configure/databases/data-purging.md
@@ -668,7 +671,6 @@ nav:
- Encryption:
- Symmetric encryption:
- Symmetric encryption: deploy/security/symmetric-encryption/index.md
- - Configure symmetric key encryption: deploy/security/symmetric-encryption/use-symmetric-encryption.md
- Symmetric data encryption key rotation: deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
- Asymmetric encryption:
- Asymmetric encryption: deploy/security/asymmetric-encryption/index.md
@@ -882,6 +884,18 @@ nav:
- Financial-grade API: references/financial-grade-api.md
- App-native authentication: references/app-native-authentication.md
- OIDC session management: references/concepts/oidc-session-management.md
+ - React Guide:
+ - Introduction: complete-guides/react/introduction.md
+ - Prerequisite: complete-guides/react/prerequisite.md
+ - Configure an application: complete-guides/react/register-an-application.md
+ - Create a React app: complete-guides/react/create-a-react-app.md
+ - Configure Asgardeo SDK: complete-guides/react/install-asgardeo-sdk.md
+ - Add login and logout: complete-guides/react/add-login-and-logout.md
+ - Display user details: complete-guides/react/display-logged-in-user-details.md
+ - Securing Routes: complete-guides/react/securing-routes-within-the-app.md
+ - Accessing protected API : complete-guides/react/accessing-protected-api.md
+ - Manage tokens in React : complete-guides/react/manage-tokens-in-React-apps.md
+ - Next Steps: complete-guides/react/next-steps.md
not_in_nav: |
diff --git a/en/identity-server/is_common.yml b/en/identity-server/is_common.yml
index e112f96108..596c44aae4 100644
--- a/en/identity-server/is_common.yml
+++ b/en/identity-server/is_common.yml
@@ -35,6 +35,7 @@ extra:
product: is
product_name: *site_name
nav_list:
+ - Home
- Get Started
- Guides
- Setup
diff --git a/en/identity-server/next/docs/apis/restapis/actions.yaml b/en/identity-server/next/docs/apis/restapis/actions.yaml
index f03b99d6fa..243a757910 100644
--- a/en/identity-server/next/docs/apis/restapis/actions.yaml
+++ b/en/identity-server/next/docs/apis/restapis/actions.yaml
@@ -505,127 +505,6 @@ paths:
curl --location --request POST 'https://localhost:9443/api/server/v1/actions/{actionType}/{actionId}/deactivate' \
-H 'Authorization: Basic YWRtaW46YWRtaW4='
- /actions/{actionType}/{actionId}/{authType}:
- put:
- tags:
- - Actions Endpoint
- summary: Update Action Authentication
- description: "This API updates authentication mechanism for the endpoint configured for the action. \n\n
- Scope (Permission) required: ``internal_action_mgt_update``\n\n"
- operationId: updateActionEndpointAuthentication
- parameters:
- - name: actionType
- in: path
- description: Name of the Action Type.
- required: true
- schema:
- enum:
- - preIssueAccessToken
- - name: actionId
- in: path
- description: Unique identifier of the action.
- required: true
- schema:
- type: string
- - name: authType
- in: path
- description: Authentication Type of the Action Endpoint.
- required: true
- schema:
- enum:
- - none
- - basic
- - apiKey
- - bearer
- requestBody:
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/AuthTypeProperties'
- description: This represents the updating authentication mechanism for the endpoint configured.
- required: true
- responses:
- '200':
- description: OK
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/ActionResponse'
- '400':
- description: Bad Request
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- '401':
- description: Unauthorized
- '403':
- description: Forbidden
- '404':
- description: Not Found
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- '500':
- description: Server Error
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- '501':
- description: Not Implemented
- content:
- application/json:
- schema:
- $ref: '#/components/schemas/Error'
- x-codeSamples:
- - lang: Curl(Bearer)
- source: |
- curl --location --request PUT 'https://localhost:9443/api/server/v1/actions/{actionType}/{actionId}/bearer' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Basic YWRtaW46YWRtaW4=' \
- -d '{
- "properties": {
- "accessToken": "token"
- }
- }'
- - lang: Curl(Basic)
- source: |
- curl --location --request PUT 'https://localhost:9443/api/server/v1/actions/{actionType}/{actionId}/basic' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Basic YWRtaW46YWRtaW4=' \
- -d '{
- "properties": {
- "username": "username",
- "password": "password"
- }
- }'
- - lang: Curl(API Key)
- source: |
- curl --location --request PUT 'https://localhost:9443/api/server/v1/actions/{actionType}/{actionId}/apiKey' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Basic YWRtaW46YWRtaW4=' \
- -d '{
- "properties": {
- "header": "header",
- "value": "value"
- }
- }'
- - lang: Curl(None)
- source: |
- curl --location --request PUT 'https://localhost:9443/api/server/v1/actions/{actionType}/{actionId}/none' \
- -H 'Content-Type: application/json' \
- -H 'Accept: application/json' \
- -H 'Authorization: Basic YWRtaW46YWRtaW4=' \
- -d '{
- "properties": {}
- }'
- x-codegen-request-body-name: body
-
components:
securitySchemes:
BasicAuth:
@@ -956,13 +835,6 @@ components:
- $ref: '#/components/schemas/BearerAuthentication'
- $ref: '#/components/schemas/NoAuthentication'
- AuthTypeProperties:
- oneOf:
- - $ref: '#/components/schemas/Basic'
- - $ref: '#/components/schemas/ApiKey'
- - $ref: '#/components/schemas/Bearer'
- - $ref: '#/components/schemas/None'
-
Error:
type: object
properties:
diff --git a/en/identity-server/next/docs/apis/restapis/scim2-users.yaml b/en/identity-server/next/docs/apis/restapis/scim2-users.yaml
index 6a23feca32..1628d9123f 100644
--- a/en/identity-server/next/docs/apis/restapis/scim2-users.yaml
+++ b/en/identity-server/next/docs/apis/restapis/scim2-users.yaml
@@ -681,16 +681,39 @@ components:
$ref: '#/components/schemas/UserResponseObject'
UserSearchRequestObject:
type: object
- example:
+ properties:
schemas:
- - urn:ietf:params:scim:api:messages:2.0:SearchRequest
+ type: object
+ items:
+ type: string
+ example:
+ - urn:ietf:params:scim:api:messages:2.0:SearchRequest
attributes:
- - name.familyName
- - userName
- filter: userName sw ki and name.familyName co err
- domain: PRIMARY
- startIndex: 1
- count: 10
+ type: array
+ description: SCIM defined attributes parameter.
+ items:
+ type: string
+ example:
+ - name.familyName
+ - userName
+ filter:
+ type: string
+ description: The expression used for filtering. Supported filters are ew, eq, co, sw, and and.
+ example: userName sw ki and name.familyName co err
+ domain:
+ type: string
+ description: The name of the user store where filtering needs to be applied.
+ example: DEFAULT
+ startIndex:
+ type: integer
+ format: int32
+ description: The 1-based index of the first query result
+ example: 1
+ count:
+ type: integer
+ format: int32
+ description: Specifies the desired maximum number of query results per page.
+ example: 10
ErrorInvalidInput:
required:
- detail
diff --git a/en/identity-server/next/docs/apis/restapis/user-store.yaml b/en/identity-server/next/docs/apis/restapis/user-store.yaml
index 7a68c6df5d..f674b3f01f 100644
--- a/en/identity-server/next/docs/apis/restapis/user-store.yaml
+++ b/en/identity-server/next/docs/apis/restapis/user-store.yaml
@@ -352,7 +352,7 @@ paths:
-d '[
{
"operation": "REPLACE",
- "path": "/properties/disabled",
+ "path": "/properties/Disabled",
"value": "true"
}
]'
@@ -880,7 +880,7 @@ components:
path:
type: string
description: A JSON-Pointer
- example: /properties/disabled
+ example: /properties/Disabled
value:
type: string
description: The value to be used within the operations
diff --git a/en/identity-server/next/docs/assets/img/concepts/asgardeo-sdk.png b/en/identity-server/next/docs/assets/img/concepts/asgardeo-sdk.png
new file mode 100644
index 0000000000..b5e8eb3116
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/concepts/asgardeo-sdk.png differ
diff --git a/en/identity-server/next/docs/assets/img/concepts/asgardeo-user-stores.png b/en/identity-server/next/docs/assets/img/concepts/asgardeo-user-stores.png
new file mode 100644
index 0000000000..59dc1ef44f
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/concepts/asgardeo-user-stores.png differ
diff --git a/en/identity-server/next/docs/assets/img/concepts/login-flow-ai.png b/en/identity-server/next/docs/assets/img/concepts/login-flow-ai.png
new file mode 100644
index 0000000000..bce647931e
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/concepts/login-flow-ai.png differ
diff --git a/en/identity-server/next/docs/assets/img/concepts/login-flow.png b/en/identity-server/next/docs/assets/img/concepts/login-flow.png
new file mode 100644
index 0000000000..c93053ee5f
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/concepts/login-flow.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/account-configurations/bot-detection.png b/en/identity-server/next/docs/assets/img/guides/account-configurations/bot-detection.png
index 995165a76f..90874d9d31 100644
Binary files a/en/identity-server/next/docs/assets/img/guides/account-configurations/bot-detection.png and b/en/identity-server/next/docs/assets/img/guides/account-configurations/bot-detection.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png b/en/identity-server/next/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png
index b3d4d36326..50d5cc865d 100644
Binary files a/en/identity-server/next/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png and b/en/identity-server/next/docs/assets/img/guides/account-configurations/invite-user-to-set-password.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/authorization/access-token/access-token-attributes.png b/en/identity-server/next/docs/assets/img/guides/authorization/access-token/access-token-attributes.png
new file mode 100644
index 0000000000..b5932d8df3
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/authorization/access-token/access-token-attributes.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-app-name.png b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-app-name.png
new file mode 100644
index 0000000000..8d405387df
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-app-name.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-auth-config.png b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-auth-config.png
new file mode 100644
index 0000000000..6696b3af88
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-auth-config.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-configure-connector.png b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-configure-connector.png
new file mode 100644
index 0000000000..e45aa4ab12
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-configure-connector.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-custom-connector.png b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-custom-connector.png
new file mode 100644
index 0000000000..9975168a6a
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-custom-connector.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-key-token.png b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-key-token.png
new file mode 100644
index 0000000000..aba827b0b9
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/idp/x-idp/x-key-token.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/add-tenant.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/add-tenant.png
deleted file mode 100644
index 272219191a..0000000000
Binary files a/en/identity-server/next/docs/assets/img/guides/multitenancy/add-tenant.png and /dev/null differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/create-root-organization-modal.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/create-root-organization-modal.png
new file mode 100644
index 0000000000..9e8da1986f
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/create-root-organization-modal.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/new-root-organization.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/new-root-organization.png
new file mode 100644
index 0000000000..4cd86793fd
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/new-root-organization.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organizaiton-listing.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organizaiton-listing.png
new file mode 100644
index 0000000000..8441eab80b
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organizaiton-listing.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-advanced-search.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-advanced-search.png
new file mode 100644
index 0000000000..1938cc5975
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-advanced-search.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-basic-search.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-basic-search.png
new file mode 100644
index 0000000000..d321637647
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-basic-search.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-card-actions.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-card-actions.png
new file mode 100644
index 0000000000..02b0ac5bed
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-card-actions.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-details.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-details.png
new file mode 100644
index 0000000000..2f8c83c9ed
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organization-details.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organizations-dropdown.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organizations-dropdown.png
new file mode 100644
index 0000000000..b61f70318f
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/multitenancy/root-organizations-dropdown.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/multitenancy/view-tenants.png b/en/identity-server/next/docs/assets/img/guides/multitenancy/view-tenants.png
deleted file mode 100644
index 9f36086f00..0000000000
Binary files a/en/identity-server/next/docs/assets/img/guides/multitenancy/view-tenants.png and /dev/null differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png b/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png
index e8ddb8f34b..cb7c29e3b0 100644
Binary files a/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png and b/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attribute-mappings.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png b/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png
index 323672e8a5..c220d531d8 100644
Binary files a/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png and b/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-general.png b/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-general.png
index 93f10dcad1..75016635ec 100644
Binary files a/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-general.png and b/en/identity-server/next/docs/assets/img/guides/organization/attributes/edit-attributes-general.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/attributes/enable-for-user-store.png b/en/identity-server/next/docs/assets/img/guides/organization/attributes/enable-for-user-store.png
new file mode 100644
index 0000000000..35c36bcee9
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/organization/attributes/enable-for-user-store.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/recover-your-username.png b/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/recover-your-username.png
new file mode 100644
index 0000000000..f45a0d59d8
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/recover-your-username.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/username-recovery-channel-selection.png b/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/username-recovery-channel-selection.png
new file mode 100644
index 0000000000..644d0fa203
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/username-recovery-channel-selection.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/username-recovery-claim.png b/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/username-recovery-claim.png
new file mode 100644
index 0000000000..9db0cf4ca4
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/organization/self-service/customer/username-recovery-claim.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/users/migrate-users/create-a-component.png b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/create-a-component.png
new file mode 100644
index 0000000000..5a214f3db4
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/create-a-component.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/users/migrate-users/migrate-users-visual.png b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/migrate-users-visual.png
new file mode 100644
index 0000000000..4cbe1f6c77
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/migrate-users-visual.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/users/migrate-users/polling-make-open-endpoint.png b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/polling-make-open-endpoint.png
new file mode 100644
index 0000000000..20faadfac8
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/polling-make-open-endpoint.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/users/migrate-users/service-details.png b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/service-details.png
new file mode 100644
index 0000000000..eb4f4f881a
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/service-details.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/users/migrate-users/silent-user-migration.png b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/silent-user-migration.png
new file mode 100644
index 0000000000..5f0c1c4b2e
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/silent-user-migration.png differ
diff --git a/en/identity-server/next/docs/assets/img/guides/users/migrate-users/wait-page.png b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/wait-page.png
new file mode 100644
index 0000000000..d1d192c963
Binary files /dev/null and b/en/identity-server/next/docs/assets/img/guides/users/migrate-users/wait-page.png differ
diff --git a/en/identity-server/next/docs/concepts/add-login.md b/en/identity-server/next/docs/concepts/add-login.md
new file mode 100644
index 0000000000..bea0e89133
--- /dev/null
+++ b/en/identity-server/next/docs/concepts/add-login.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/add-login.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/concepts/api-security.md b/en/identity-server/next/docs/concepts/api-security.md
new file mode 100644
index 0000000000..ed3be72922
--- /dev/null
+++ b/en/identity-server/next/docs/concepts/api-security.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/api-security.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/concepts/basic-concepts.md b/en/identity-server/next/docs/concepts/basic-concepts.md
new file mode 100644
index 0000000000..5d7d7595d9
--- /dev/null
+++ b/en/identity-server/next/docs/concepts/basic-concepts.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/basic-concepts.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/concepts/customer-iam.md b/en/identity-server/next/docs/concepts/customer-iam.md
new file mode 100644
index 0000000000..abec1a16fe
--- /dev/null
+++ b/en/identity-server/next/docs/concepts/customer-iam.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/customer-iam.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/concepts/index.md b/en/identity-server/next/docs/concepts/index.md
new file mode 100644
index 0000000000..66813dff99
--- /dev/null
+++ b/en/identity-server/next/docs/concepts/index.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/index.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/concepts/workforce-iam.md b/en/identity-server/next/docs/concepts/workforce-iam.md
new file mode 100644
index 0000000000..05a302add4
--- /dev/null
+++ b/en/identity-server/next/docs/concepts/workforce-iam.md
@@ -0,0 +1 @@
+{% include "../../../../includes/concepts/workforce-iam.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-datasource-bpsds.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-datasource-bpsds.md
deleted file mode 100644
index b4f05c586e..0000000000
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-datasource-bpsds.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# Change the Default Datasource for BPS
-
-This document guides you to change the underlying databases that are
-used in business process service(BPS) components.
-
-By default WSO2 Identity Server uses the Embedded H2 database as the BPS
-datasource. However, you can change this to any database type that is
-supported by WSO2 Identity Server.
-
-Following are the sample configuration for each database type.
-
-??? example "PostgreSQL"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:postgresql://localhost:5432/gregdb"
- username = "regadmin"
- password = "regadmin"
- driver = "org.postgresql.Driver"
-
- [bps_database.config.pool_options]
- defaultAutoCommit=true
- commitOnReturn=true
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/postgresql.sql` file against the created database.
-
-??? example "MySQL"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:mysql://localhost:3306/IAMtest?useSSL=false"
- username = "root"
- password = "root"
- driver = "com.mysql.jdbc.Driver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/mysql.sql` file against the created database.
-
-
-??? example "DB2"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:db2://192.168.108.31:50000/test"
- username = "db2inst1"
- password = "db2inst1"
- driver = "com.ibm.db2.jcc.DB2Driver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/db2.sql` file against the created database.
-
-
-??? example "MSSQL"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:sqlserver://localhost:1433;databaseName=test;SendStringParametersAsUnicode=false"
- username = "sa"
- password = "pass#word2"
- driver = "com.microsoft.sqlserver.jdbc.SQLServerDriver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/mssql.sql` file against the created database.
-
-
-??? example "Oracle"
-
- 1. Configure the `/repository/conf/deployment.toml` file.
-
- ```
- [bps_database.config]
- url = "jdbc:oracle:thin:@localhost:1521/ORCLPDB"
- username = "IS590Test"
- password = "ora12c"
- driver = "oracle.jdbc.OracleDriver"
- ```
-
- 2. Execute the database scripts.
-
- Execute the scripts in the `/dbscripts/bps/bpel/create/oracle.sql` file against the created database.
-
-
-**Advanced BPS Database Configurations**
-
-Apart from the above basic configurations, WSO2 Identity Server supports the following advanced BPS database configurations.
-
- ``` toml
- [bps_database.config.pool_options]
- maxActive = "50"
- maxWait = "60000"
- minIdle = "5"
- testOnBorrow = true
- validationInterval = "30000"
- validationQuery = "SELECT 1; COMMIT"
- ```
-
-The descriptions for the advanced configurations can be found in the [Performance Tuning]({{base_path}}/deploy/performance/performance-tuning-recommendations/#jdbc-pool-configuration) documentation.
\ No newline at end of file
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md
index 7336c405b1..ab5e289c8b 100644
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md
+++ b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-ibm-db2.md
@@ -71,10 +71,8 @@ A sample configuration is given below.
1. Execute database scripts.
Execute the scripts in the `/dbscripts/db2.sql` file, against the database created.
-
-3. If you have a requirement in using workflow feature, follow [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds).
-4. Download the DB2 JDBC driver for the version, you are using and copy it to the `/repository/components/lib` folder.
+3. Download the DB2 JDBC driver for the version, you are using and copy it to the `/repository/components/lib` folder.
---
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mssql.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mssql.md
index 248ab491f9..d33001f457 100644
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mssql.md
+++ b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mssql.md
@@ -84,11 +84,8 @@ A sample configuration is given below.
falsefalse
```
-
-3. If you have a requirement in using workflow feature follow,
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the MS SQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
+3. Download the MS SQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
---
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mysql.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mysql.md
index 478893a7f4..b5892dc92c 100644
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mysql.md
+++ b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-mysql.md
@@ -95,11 +95,8 @@ A sample configuration is given below.
falsefalse
```
-
-3. If you have a requirement in using workflow feature follow,
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the MySQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
+3. Download the MySQL JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
---
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md
index fe730967d1..8d2c3bef0b 100644
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md
+++ b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle-rac.md
@@ -83,11 +83,8 @@ A sample configuration is given below.
2. Execute database scripts.
Execute the scripts in the `/dbscripts/oracle_rac.sql` file against the database created.
-
-3. If you have a requirement in using workflow feature follow,
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the Oracle RAC JDBC driver for the version, you are using and
+3. Download the Oracle RAC JDBC driver for the version, you are using and
copy it to the `/repository/components/lib` folder
---
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle.md
index 0bf6159d11..e9d2ffac6b 100644
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle.md
+++ b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-oracle.md
@@ -67,11 +67,8 @@ A sample configuration is given below.
Execute the scripts in the following file, against the database created.
- `/dbscripts/oracle.sql`
-
-3. If you have a requirement to use the workflow feature, see
- [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds)
-4. Download the Oracle JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
+3. Download the Oracle JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder
---
diff --git a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md
index 0549f76118..c3279650df 100644
--- a/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md
+++ b/en/identity-server/next/docs/deploy/configure/databases/carbon-database/change-to-postgresql.md
@@ -63,10 +63,8 @@ A sample configuration is given below.
2. Execute database scripts.
Execute the scripts in the `/dbscripts/postgresql.sql` file against the database created.
-
-3. If you have a requirement to use the workflow feature, see [Change the default database of BPS database]({{base_path}}/deploy/configure/databases/carbon-database/change-datasource-bpsds).
-4. Download the Postgres JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
+3. Download the Postgres JDBC driver for the version you are using and copy it to the `/repository/components/lib` folder.
---
diff --git a/en/identity-server/next/docs/deploy/deployment-guide.md b/en/identity-server/next/docs/deploy/deployment-guide.md
index 7abc918642..337cee0e3b 100644
--- a/en/identity-server/next/docs/deploy/deployment-guide.md
+++ b/en/identity-server/next/docs/deploy/deployment-guide.md
@@ -64,7 +64,7 @@ The above recommendations can change based on the expected concurrency and perfo
Java
-
Oracle JDK 1.8
+
Open JDK 11
Web browsers
diff --git a/en/identity-server/next/docs/deploy/environment-compatibility.md b/en/identity-server/next/docs/deploy/environment-compatibility.md
index 9b9e09cc34..0229aae4c6 100644
--- a/en/identity-server/next/docs/deploy/environment-compatibility.md
+++ b/en/identity-server/next/docs/deploy/environment-compatibility.md
@@ -11,11 +11,9 @@ As WSO2 Identity Server is a Java application, you can generally run it on most
Tested JDK versions
-
OpenJDK 11
-
OpenJDK 17
-
Oracle JDK 11
-
Oracle JDK 17
-
AdoptOpenJDK 11
+
Temurin OpenJDK 11
+
Temurin OpenJDK 17
+
Temurin OpenJDK 21
diff --git a/en/identity-server/next/docs/deploy/security/asymmetric-encryption/index.md b/en/identity-server/next/docs/deploy/security/asymmetric-encryption/index.md
index 76cfeeac24..c3515b70da 100644
--- a/en/identity-server/next/docs/deploy/security/asymmetric-encryption/index.md
+++ b/en/identity-server/next/docs/deploy/security/asymmetric-encryption/index.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/asymmetric-encryption.md" %}
+{% include "../../../../../../includes/deploy/security/asymmetric-encryption/index.md" %}
diff --git a/en/identity-server/next/docs/deploy/security/keystores/configure-keystores.md b/en/identity-server/next/docs/deploy/security/keystores/configure-keystores.md
index 6b4991a739..fdb4c07e91 100644
--- a/en/identity-server/next/docs/deploy/security/keystores/configure-keystores.md
+++ b/en/identity-server/next/docs/deploy/security/keystores/configure-keystores.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/configure-keystores.md" %}
\ No newline at end of file
+{% include "../../../../../../includes/deploy/security/keystores/configure-keystores.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/deploy/security/keystores/create-new-keystores.md b/en/identity-server/next/docs/deploy/security/keystores/create-new-keystores.md
index c598f55db7..642c43e47d 100644
--- a/en/identity-server/next/docs/deploy/security/keystores/create-new-keystores.md
+++ b/en/identity-server/next/docs/deploy/security/keystores/create-new-keystores.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/create-new-keystores.md" %}
+{% include "../../../../../../includes/deploy/security/keystores/create-new-keystores.md" %}
diff --git a/en/identity-server/next/docs/deploy/security/keystores/index.md b/en/identity-server/next/docs/deploy/security/keystores/index.md
index 0c124b4c79..03c5b76111 100644
--- a/en/identity-server/next/docs/deploy/security/keystores/index.md
+++ b/en/identity-server/next/docs/deploy/security/keystores/index.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/index.md" %}
+{% include "../../../../../../includes/deploy/security/keystores/index.md" %}
diff --git a/en/identity-server/next/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md b/en/identity-server/next/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
index 0e9f8753db..1b3e14c893 100644
--- a/en/identity-server/next/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
+++ b/en/identity-server/next/docs/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md" %}
+{% include "../../../../../../includes/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md" %}
diff --git a/en/identity-server/next/docs/deploy/security/security-guidelines/product-level-security-guidelines.md b/en/identity-server/next/docs/deploy/security/security-guidelines/product-level-security-guidelines.md
index dc6b3c77a8..7145e680b2 100644
--- a/en/identity-server/next/docs/deploy/security/security-guidelines/product-level-security-guidelines.md
+++ b/en/identity-server/next/docs/deploy/security/security-guidelines/product-level-security-guidelines.md
@@ -227,7 +227,7 @@ Log forging can be prevented by appending a UUID to the log message.
## JVM parameters
-- The recommended JDK versions are JDK 1.8 and 11. For more information, see Prerequisites.
+- The recommended JDK versions are JDK 11 and 17. For more information, see Prerequisites.
```java
-Xms512m -Xmx2048m
diff --git a/en/identity-server/next/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md b/en/identity-server/next/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
index 3bbdfe34c3..e4488efe7c 100644
--- a/en/identity-server/next/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
+++ b/en/identity-server/next/docs/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
@@ -1,250 +1 @@
-# Blue-Green Data Encryption Key Rotation
-
-This section contains the complete process you need to follow in order to perform symmetric data encryption key rotation in WSO2 Identity Sever(WSO2 IS version 5.11.0 and above).
-
-Key rotation can be defined as retiring an encryption key and replacing it with a new key. Data is encrypted using a key known as a Data Encryption Key(DEK) and the DEK is then encrypted with another key called Key Encryption Key(KEK). This is known as envelope encryption. Frequent rotations of these encryption keys are considered as an industry best practice by PCI DSS and NIST standards.
-
-## Why should you rotate encryption keys?
-
-!!! info
- Originator Usage Period (OUP) is the time period during which encryption is applied to data.
-
-- A cryptoperiod is the time span during which a specific key is authorized for use. [NIST SP 800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf){:target="_blank"} recommends different cryptoperiods for different encryption key types.
-
- - Symmetric Data Encryption Keys
-
- - OUP recommended for large volumes of data is about a day or a week.
- - OUP recommended for smaller volumes of data is about 2 years.
-
- - Symmetric Key, Wrapping Keys
-
- - OUP recommended for a key that wraps a large number of keys is about a day or a week.
- - OUP recommended for a key that wraps a smaller number of keys is up to 2 years.
-
-- Security compliance requirements
-- Security breach requirements
-
-!!! note
- The above-mentioned cryptoperiods can vary based on other factors like the sensitivity of data and the amount of data we have.
-
-## Background
-
-WSO2 Identity Server has the following key usages for signing/encrypting data and each of these types will have different key rotation requirements.
-
-- TLS Connection
-- Signing and encryption of data (JWT assertions, payloads) shared with external parties (SP, IdP).
-- Encryption of sensitive runtime level configuration secrets/user data persisted in datastores and user stores.
-- Encryption of sensitive deployment-level configuration data in configuration files.
-
-From WSO2 IS 5.11.0 onwards, symmetric encryption is used to encrypt the internal sensitive runtime data above. The DEK used to encrypt these data is configured in the `deployment.toml` file and it is protected by a KEK. The secure vault is utilized as of now to protect this DEK. Here, only the rotation of the Data Encryption Key configured in the `deployment.toml` file is considered.
-
-## DEK rotation frequency
-
-In the case of a security compliance requirement, we can see that symmetric DEK rotation can be done in 2 years or less based on the volume of data present.
-
-In a security breach scenario, we must rotate the DEK immediately and re-encrypt all the data to the new DEK.
-
-## Key Rotation Approach
-
-WSO2 IS has introduced an external tool that re-encrypts internal data after rotation of the configured symmetric data encryption key. Here, the re-encryption of the identity and registry databases and some configuration files is considered. Apart from that, the tool syncs end-user data that gets generated in the live system to the new setup.
-
-The external Java client that performs the above tasks can be created by following the steps [here](#how-to-create-the-key-rotation-tool).
-
-## Tables that support re-encryption
-
-At the moment, the tables given below are supported for re-encryption.
-
-| **Table** | **Fields** |
-|-----------|---------------|
-| IDN_IDENTITY_USER_DATA | TOTP secretKey and verifiedSecretKey claims |
-| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth2 authorization codes |
-| IDN_OAUTH2_ACCESS_TOKEN | OAuth2 access and refresh tokens |
-| IDN_OAUTH_CONSUMER_APPS | Consumer secrets
-| WF_BPS_PROFILE | BPS profile password |
-| WF_REQUEST | WF request credentials |
-| REG_PROPERTY | Keystore passwords, Keystore privatekeyPass, and Entitlement subscriberPasswords |
-
-## Configuration files that support re-encryption
-
-At the moment, the configuration files given below are supported for re-encryption.
-
-| **Configuration file** | **Path** | **Property** |
-|---------------------------|-----------|--------------|
-| Event publishers | `/repository/deployment/server/eventpublishers` files | Password |
-| Super tenant secondary user stores | `/repository/deployment/server/userstores/` files | Password |
-| Tenant secondary userstores | `/repository/tenants//userstores/` files | Password |
-
-## Tables that support syncing
-
-At the moment, the tables given below can be synced during key rotation from the old setup to the new setup. Any other data will not be persisted in the new setup.
-
-| **Table** | **Purpose** | **Recommendation** |
-|-----------|---------------|-----------------------|
-| IDN_IDENTITY_USER_DATA | Identity claims when the identity data store is enabled | Usually recommended to sync if identity management features are enabled in the system |
-| IDN_OAUTH2_ACCESS_TOKEN | OAuth 2.0 tokens | Need to sync if the tokens created during the key rotation period need to be valid after key rotation |
-| IDN_OAUTH2_ACCESS_TOKEN_SCOPE | OAuth 2.0 scopes | If the IDN_OAUTH2_ACCESS_TOKEN is synced, this table also needs to be synced |
-| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth 2.0 authorization codes | Need to sync if the authorization codes created during the key rotation period need to be valid after key rotation |
-
-## How To Create The Key Rotation Tool
-
-!!! note
- In this section, `` is the directory where the current Identity Server resides, and `` is the directory where the copy of the current Identity Server resides. `` refers to the location [here](https://github.com/wso2/identity-tools/components/org.wso2.carbon.identity.keyrotation){:target="_blank"} and the `` refers to the location of the external tool.
-
-1. Clone the repository, [identity-tools](https://github.com/wso2/identity-tools){:target="_blank"}.
-
-2. Build it using maven by running the command `mvn clean install`.
-
-3. Go to the `/target` folder and copy the `keyrotation-tool--SNAPSHOT.jar` file and the `/target/lib` folder to ``. Get the `properties.yaml` file, `keyrotation.sh` file, and the `triggers` folder from `/src/main/resources` and copy them to the same `` location.
-
-## Performing blue-green key rotation
-
-1. Block all privileged user flows and allow only end-user flows.
-
- !!! note
- For the privileged user flows, block all admin services from the load balancer and the management console as well. For end user flows, the above [tables]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation/#tables-that-support-re-encryption) will be synced to the ``, so only these end user data flows should be allowed to generate in ``.
-
-2. Execute the `old.sql` script in the `` identity database to create temp tables and triggers. The triggers can be found inside the `/triggers` folder.
-
-3. Create a copy of the ``(This copied directory will be referred to as the `NEW_IS_HOME`) and dump `` identity and registry databases and create the new databases.
-
-4. Drop the temp tables and triggers in the `` identity database using the `new.sql` script. The triggers can be found inside the `/triggers` folder.
-
-5. Open the `properties.yaml` file in `` and edit the configurations accordingly.
-
- - oldSecretKey - The symmetric encryption key used in the ``.
-
- !!! note
- If the key is encrypted using cipher tool, decrypt it back as shown [here](https://shagihan.medium.com/decrypt-encrypted-text-with-the-wso2-cipher-tool-15b67624620a){:target="_blank"}.
-
- - newSecretKey - The new symmetric encryption key.
-
- !!! tip
- Generate using a tool like openssl using the command, `openssl rand -hex 16`.
-
- - newISHome - The absolute path of the ``.
- - oldIdnDBUrl - `` identity database URL.
- - oldIdnUsername - `` identity database username.
- - oldIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
- - newIdnDBUrl - `` identity database URL.
- - newIdnUsername - `` identity database username.
- - newIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
- - newRegDBUrl - `` registry database URL.
- - newRegUsername - `` registry database username.
- - newRegPassword - `` registry database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
- - enableDBMigrator - Enable/disable re-encryption for the identity and registry databases.
-
- !!! note
- Keep this always **true** to avoid unnecessary issues.
-
- - enableConfigMigrator - Enable/disable re-encryption for the configuration files.
-
- !!! note
- Keep this always **true** to avoid unnecessary issues.
-
- - enableSyncMigrator - Enable/disable syncing mechanism.
-
- !!! note
- You only need to set this to **true**, if you have opted in for blue-green key rotation with zero downtime for the end user flows.
-
- - chunkSize - Size of the record chunks being retrieved from the database tables for syncing.
-
- ??? tip "Sample configuration written for the properties.yaml file"
-
- ```
- oldSecretKey: AFA27B44D43B02A9FEA41D13CEDC2E40
- newSecretKey: 1fc0bc7a3805b42afa5f5af07a595f56
- newISHome: /home/IS/wso2is-5.12.0
- oldIdnDBUrl: jdbc:mysql://localhost:3306/regdb?useSSL=false
- oldIdnUsername: root
- oldIdnPassword: cm9vdA==
- newIdnDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false
- newIdnUsername: root
- newIdnPassword: cm9vdA==
- newRegDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false
- newRegUsername: root
- newRegPassword: cm9vdA==
- enableDBMigrator: true
- enableConfigMigrator: true
- enableSyncMigrator: true
- chunkSize: 2
- ```
-
- ??? tip "Sample configurations written for DB type URL"
- **H2 DB**
- ```
- jdbc:h2:~/Desktop/IS/copy/wso2is-5.11.0-beta5-SNAPSHOT/repository/database/WSO2IDENTITY_DB
- ```
- **MySQL**
- ```
- jdbc:mysql://localhost:3306/idndb?useSSL=false
- ```
- **DB2**
- ```
- jdbc:db2://localhost:50000/idndb
- ```
- **PostgreSQL**
- ```
- jdbc:postgresql://localhost:5432/idndb
- ```
- **MSSQL**
- ```
- jdbc:sqlserver://localhost:1433;databaseName=idndb
- ```
- **Oracle DB**
- ```
- jdbc:oracle:thin:@localhost:1521/ORCLCDB.LOCALDOMAIN
- ```
-
-6. Run the tool using the `./keyrotation.sh keyrotation-tool--SNAPSHOT.jar` command from ``.
-
-7. Edit the `` `deployment.toml` file having the new configured databases and the new key.
-
-8. Start `` once the re-encryption for the existing DB and config file is done.
-
-9. When no new entries are being synced in the logs, route traffic to `` and enable all load balancer API endpoints(privileged and end-user flows).
-
-!!! note "Important"
- Do not stop the tool at once, let it sync any remaining data in the temp tables after routing the traffic.
-
-## Verifying the key rotation
-
-- Check the log files to verify if re-encryption happened successfully for the 7 identity and registry database tables. Check the logs given below for the successful/failed re-encryption counts of OAuth2 access and refresh tokens.
-
- ??? tip "DB log sample"
- ```
- Successfully updated OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 897
- Failed OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 0
- ```
-
- !!! note
- If the key rotation task is successful, the failed logs count should be `0` for all the tables.
-
-- Check the log files to verify if re-encryption happened successfully for the 3 configuration files. Check the logs given below for the successful/failed re-encryption counts of event publisher configuration files.
-
- ??? tip "Config file log sample"
- ```
- Updated event publisher configuration files: 8
- Failed event publisher configuration files: 0
- ```
-
- !!! note
- If the key rotation task is successful, the failed logs count should be `0` for all the configuration files.
-
-- Check the log files to verify if the transformation of the synced data happened successfully for the 4 tables. Check the logs given below for the successful/failed transformation counts of `IDN_IDENTITY_USER_DATA` table.
-
- ??? tip "Synced log sample"
- ```
- Successfully transformed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 2
- Transformation failed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 0
- ```
-
- !!! note
- If the synced task is successful, the failed logs count should be `0` for all the synced tables.
-
-- Check for any errors in the log files and carefully analyze the logs if the error can be ignored and other steps can be proceeded with. Otherwise, check what has caused the error.
-
-## Recovering from any failure
-
-If the key rotation task stops midway, follow the blue green key rotation user guide steps again.
-
-If there are errors logged in the log files, carefully go through the errors and find what has caused the error.
+{% include "../../../../../../includes/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/deploy/security/symmetric-encryption/index.md b/en/identity-server/next/docs/deploy/security/symmetric-encryption/index.md
index d72560d24d..57c104b7f5 100644
--- a/en/identity-server/next/docs/deploy/security/symmetric-encryption/index.md
+++ b/en/identity-server/next/docs/deploy/security/symmetric-encryption/index.md
@@ -1 +1 @@
-{% include "../../../../../../includes/guides/encryption/symmetric-encryption.md" %}
+{% include "../../../../../../includes/deploy/security/symmetric-encryption/index.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/deploy/security/symmetric-encryption/use-symmetric-encryption.md b/en/identity-server/next/docs/deploy/security/symmetric-encryption/use-symmetric-encryption.md
deleted file mode 100644
index 74ffaa5bca..0000000000
--- a/en/identity-server/next/docs/deploy/security/symmetric-encryption/use-symmetric-encryption.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Configurations Related to Symmetric Key Encryption
-
-This section explains the configurations related to [symmetric key encryption]({{base_path}}/deploy/security/symmetric-encryption). This version of WSO2 Identity Server uses symmetric encryption by default. You can switch to [asymmetric key encryption]({{base_path}}/deploy/security/asymmetric-encryption/use-asymmetric-encryption) if required.
-
-## Algorithm used
-
-`AES/GCM/NoPadding` is used as the symmetric key encryption algorithm.
-
-GCM is a stream cipher. Hence, there is a performance advantage of using it due to the parallel encryption of each block. There is no need to use a padding mechanism in GCM mode. In GCM mode, the initialization vector (IV) should be a unique value for each encryption request. The corresponding IVs of each unique value should be kept track of in order to decrypt this internal data. The keysize supported is AES-128.
-
-The following configuration is enabled by default in the `/repository/conf/carbon.properties` file for the algorithm to be used.
-
-```xml
-org.wso2.CipherTransformation=AES/GCM/NoPadding
-```
-
-## Internal crypto provider
-
-The `org.wso2.carbon.crypto.provider.SymmetricKeyInternalCryptoProvider` provider is used as the internal crypto provider. When configuring the `SymmetricKeyInternalCryptoProvider`, the secret key value needs to be provided in the configuration as well.
-
-The following configuration is enabled by default in the `/repository/resources/conf/default.json` file to use the above-mentioned internal crypto provider.
-
-```xml
-"encryption.internal_crypto_provider": "org.wso2.carbon.crypto.provider.SymmetricKeyInternalCryptoProvider",
-"encryption.key": "03BAFEB27A8E871CAD83C5CD4E771DAB"
-```
-
-The corresponding xml configuration can be found in the `/repository/conf/carbon.xml` file.
-
-```xml
-org.wso2.carbon.crypto.provider.SymmetricKeyInternalCryptoProvider
-03BAFEB27A8E871CAD83C5CD4E771DAB
-```
-
-The `encryption.key` or `` value above is a sample value. Generate a unique secret key of 128 bytes using a tool like OpenSSL as shown below.
-
-```xml
-openssl rand -hex 16
-```
-
-Once a secure secret key is generated, configure it using the following configuration in the `/repository/conf/deployment.toml` file.
-
-```toml
-[encryption]
-key = "3cc0481b70794667b5bee7e2beed2de4"
-```
-
-## Userstore password encryption
-
-In the previous versions, there was a configuration to enable the preferred keystore (internal or primary) to encrypt secondary userstore passwords.
-However, with symmetric key encryption, keystore references are not required. So this configuration has a blank as its value.
-
-```toml
-"keystore.userstore_password_encryption": "",
-```
-
-## Encrypting symmetric encryption key with cipher tool
-
-It is advised to encrypt the symmetric encryption key with a cipher tool as mentioned [here]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool).
diff --git a/en/identity-server/next/docs/get-started/try-samples/ws-federation-webapp.md b/en/identity-server/next/docs/get-started/try-samples/ws-federation-webapp.md
index 593b92deee..18295a2669 100644
--- a/en/identity-server/next/docs/get-started/try-samples/ws-federation-webapp.md
+++ b/en/identity-server/next/docs/get-started/try-samples/ws-federation-webapp.md
@@ -107,14 +107,14 @@ To configure additional properties for the sample application:
6. Click **Update** to save your configurations.
!!! tip
- Currently, the signing algorithm used for WS-Federation by default is `rsa-sha1`, and the digest algorithm used is `sha1`.
+ Currently, the signing algorithm used for WS-Federation by default is `rsa-sha256`, and the digest algorithm used is `sha256`.
To change the default algorithms, add the following configuration in the `deployment.toml` file found in the `/repository/conf` directory.
- The example given below sets the signing algorithm to `rsa-sha256` and the digest algorithm to `sha256`.
+ The example given below sets the signing algorithm to `rsa-sha1` and the digest algorithm to `sha1`.
```toml
[sts]
- signature_algorithm = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
- digest_algorithm = "http://www.w3.org/2001/04/xmlenc#sha256"
+ signature_algorithm = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha1"
+ digest_algorithm = "http://www.w3.org/2001/04/xmlenc#sha1"
```
## Try it out
diff --git a/en/identity-server/next/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md b/en/identity-server/next/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md
index 9bddebbacb..34ef476337 100644
--- a/en/identity-server/next/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md
+++ b/en/identity-server/next/docs/guides/account-configurations/user-onboarding/invite-user-to-set-password.md
@@ -7,10 +7,10 @@ Allow administrator to invite users to set their own passwords during the onboar
For inviting users to set their password, follow these instructions:
1. On the {{product_name}} Console, go to **Login & Registration** > **User Onboarding** > **Invite User to Set Password**.
-2. Check the **Enable user email verification** if a verification step is required during user creation.
-3. Select the **Enable account lock on creation** to lock the user account during creation.
-4. If you want to send an account activation email, make sure the corresponding option is enabled.
-5. Set the **Email verification code expiry time** and **Ask password code expiry time** to define how long the codes should be valid.
+2. Check the **Enable email invitations for user password setup** to send an email to the user to set the password after user creation.
+3. Select the **Enable account lock on creation** to lock the user account during user creation.
+4. If you want to send an account activation confirmation email, enable the **Send account activation email**.
+5. Set the **Password setup invitation code expiration time** in minutes to define how long the password setup invitation e-mail would be valid. For infinite validity period, set -1. Setting 0 will cause immediate expiry of the invitation
6. Click **Update** to save the changes.
![Invite User to Set Password Configuration]({{base_path}}/assets/img/guides/account-configurations/invite-user-to-set-password.png){: width="700" style="display: block; margin: 0;"}
diff --git a/en/identity-server/next/docs/guides/authentication/app-native-authentication/index.md b/en/identity-server/next/docs/guides/authentication/app-native-authentication/index.md
new file mode 100644
index 0000000000..4247bbc9a4
--- /dev/null
+++ b/en/identity-server/next/docs/guides/authentication/app-native-authentication/index.md
@@ -0,0 +1 @@
+{% include "../../../../../../includes/guides/authentication/app-native-authentication/index.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md b/en/identity-server/next/docs/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md
new file mode 100644
index 0000000000..60d2b1ac80
--- /dev/null
+++ b/en/identity-server/next/docs/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md
@@ -0,0 +1,2 @@
+{% set product_name = "WSO2 Identity Server" %}
+{% include "../../../../../../includes/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md b/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md
deleted file mode 100644
index 8a6e3e98eb..0000000000
--- a/en/identity-server/next/docs/guides/authorization/impersonation/user-impersonation.md
+++ /dev/null
@@ -1,4 +0,0 @@
-{% set base_url = "localhost:9443" %}
-{% set base_url_sample = "localhost:9443" %}
-
-{% include "../../../../../../includes/guides/authorization/user-impersonation.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/guides/authorization/index.md b/en/identity-server/next/docs/guides/authorization/index.md
index bdc01e381e..9753b1c40a 100644
--- a/en/identity-server/next/docs/guides/authorization/index.md
+++ b/en/identity-server/next/docs/guides/authorization/index.md
@@ -1,16 +1 @@
-# Authorization
-
-The authorization guide offers detailed instructions for implementing a range of authorization scenarios within your application using {{ product_name }}, ensuring secure access and enhanced protection.
-
-## API authorization
-
-- [Role-based access control (RBAC)]({{base_path}}/guides/authorization/api-authorization/api-authorization/)
-- [Attribute-based access control (ABAC)]({{base_path}}/guides/authorization/api-authorization/attribute-based-access-control/)
-
-## Fine-grained authorization
-
-- [Fine-grained authorization]({{base_path}}/guides/authorization/fine-grained-authorization/rule-based-provisioning/)
-
-## Impersonation
-
-- [Impersonation]({{base_path}}/guides/authorization/impersonation/user-impersonation/)
\ No newline at end of file
+{% include "../../../../../includes/guides/authorization/index.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/guides/authorization/user-impersonation.md b/en/identity-server/next/docs/guides/authorization/user-impersonation.md
new file mode 100644
index 0000000000..397e07d676
--- /dev/null
+++ b/en/identity-server/next/docs/guides/authorization/user-impersonation.md
@@ -0,0 +1,4 @@
+{% set base_url = "localhost:9443" %}
+{% set base_url_sample = "localhost:9443" %}
+
+{% include "../../../../../includes/guides/authorization/user-impersonation.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/guides/multitenancy/manage-tenants.md b/en/identity-server/next/docs/guides/multitenancy/manage-tenants.md
index fd1b0e0c80..0c2e78e560 100644
--- a/en/identity-server/next/docs/guides/multitenancy/manage-tenants.md
+++ b/en/identity-server/next/docs/guides/multitenancy/manage-tenants.md
@@ -1,27 +1,44 @@
-# Tenant management
+# Manage Root Organizations (Tenants)
-By default, {{ product_name }} is configured with a single tenant named `carbon.super`. If you have the required permissions, you can configure more tenant domains and maintain multiple isolated user bases on a single server/cluster at the same time.
+!!! Note
+ **Tenants** will now be referred to as **Root Organizations**.
+
+ This change is to ensure consistency across our documentation and to better reflect the hierarchical structure of organizations.
+
+{{ product_name }}, by default, is configured with a single root organization named `carbon.super`. If you have the required permissions, you can configure more root organizations and maintain multiple isolated user bases on a single server/cluster at the same time.
!!! Info
Learn more about [multi-tenancy]({{base_path}}/guides/multitenancy/).
-## Add new tenants
+!!! note "Use REST APIs to manage root organizations"
-Follow the steps given below to add a new tenant from the Management Console.
+ {{product_name}} also offers REST APIs to conveniently manage root organizations. To try out the Tenant Management REST API, refer [here]({{base_path}}/apis/tenant-management-rest-api/).
-!!! Note
- You can access the Management Console using the following URL: `https://:/carbon`.
+## Add a root organization
+
+Follow the steps given below to add a new root organization from the {{ product_name }} Console.
-1. Sign in to the super tenant on the Management Console.
+1. Sign in to the Console of the `carbon.super` root organization.
!!! info
- To add and manage tenants using the Management Console, you need to be signed in as a super user.
+ To add and manage tenants using the {{ product_name }} Console, you need to be signed in as a super admin user. You can access the {{ product_name }} Console using the following URL:
+ `https://:/console`.
-2. Go to **Configure** > **Multitenancy** and click **Add New Tenant**.
- ![Add Tenant]({{base_path}}/assets/img/guides/multitenancy/add-tenant.png)
+2. Open the **Root Organization** dropdown from the top left corner and click **Manage Root Organizations**.
+
+ ![Root Organizations Dropdown]({{base_path}}/assets/img/guides/multitenancy/root-organizations-dropdown.png)
+
+3. On the **Root Organizations** page, click on the **New Root Organization** button.
+
+ !!! info
+ If you have already created root organizations, this page will be populated with them and the button will appear on the top right corner of the page.
-3. On the **Register A New Organization** page that opens, enter the tenant details and click **Save**.
+ ![New Root Organization]({{base_path}}/assets/img/guides/multitenancy/new-root-organization.png)
+
+4. On the modal that opens up, enter the root organization details and click **Create**.
+
+ ![Create Root Organization]({{base_path}}/assets/img/guides/multitenancy/create-root-organization-modal.png)
@@ -33,50 +50,93 @@ Follow the steps given below to add a new tenant from the Management Console.
Domain
-
The domain name (e.g., abc.com), which is used as a unique identifier for your domain. You can use it to sign in to the Management Console to be redirected to your specific tenant. The domain is also used in URLs to distinguish one tenant from another.
-
-
-
Select Usage Plan for Tenant
-
The usage plan defines limitations (such as the number of users, bandwidth, etc.) for the tenant.
+
The domain name (e.g., abc.com) is used as a unique identifier for your organization. The URL for the new root organization's Console will be `https://:/t//console` URL.
-
First Name / Last Name
-
The name of the tenant admin.
+
First Name
+
The first name of the root organization admin.
-
Admin Username
-
The sign-in username of the tenant admin. The username always ends with the domain name (e.g., admin@abc.com).
+
Last Name
+
The last name of the root organization admin.
-
Admin Password
-
The password used to sign in using the admin username specified.
-
-
-
Admin Password (Repeat)
-
Repeat the password to confirm.
+
Username
+
The username of the root organization admin that will be used for signing in.
Email
The email address of the admin.
+
+
Password
+
The password used when singing in with the username specified above.
+
-4. Once a new tenant is created, the tenant details appear in the **Tenants List** as shown below.
+5. Once a new root organization is created, it will be listed in the the **Root Organization** listing page as shown below.
-![View a tenants]({{base_path}}/assets/img/guides/multitenancy/view-tenants.png)
+ ![Root Organization Listing]({{base_path}}/assets/img/guides/multitenancy/root-organizaiton-listing.png)
-## View tenant details
+## View root organization details
-To view tenant details, follow the steps given below.
+To view the details of the root organization, follow the steps given below.
-1. Sign in to the super tenant on the Management Console.
-2. Go to **Configure** > **Multitenancy** and click **View Tenants**.
+1. Sign in to the `carbon.super` root organization on the {{ product_name }} Console.
+2. Open the **Root Organizations** dropdown from the left top corner and click **Manage Root Organizations**.
!!! info
- You will see information of all the tenants that currently exist in the system.
+ You will see information of all the root organizations that currently exist in the system.
-3. If you want to view only tenants of a specific domain, enter the domain name and click **Find**.
+3. Several actions can be performed on the root organization from the **Root Organizations** listing page itself.
+
+ ![Root Organization Actions]({{base_path}}/assets/img/guides/multitenancy/root-organization-card-actions.png)
+
+ - **Edit**: Click on the **Edit** button to navigate to the details page of the respective root organization.
+ - **More**: Click on the elipsis icon to view more actions.
+ - **Go to Console**: Navigate to the Console of the respective root organization.
+ - **Disable** / **Enable**: Depending on the current status of the root organization, you can disable or enable it.
+ - **Delete**: Delete the root organization.
+
+3. If you want to view details of a specific root organization, click on the **Edit** button of the respective root organization. Inside the root organization details page, you can perform the following actions:
+
+ - **Edit Admin Details**: You can update the first name, last name, email, and password of the root organization admin.
+ - **Disable** / **Enable**: Depending on the current status of the root organization, you can disable or enable it.
+ - **Delete**: Delete the root organization.
+
+ ![Root Organization Details]({{base_path}}/assets/img/guides/multitenancy/root-organization-details.png)
+
+## Filter root organizations
+
+The root organizations page provides a powerful search and filtering feature to help you easily locate specific root organizations.
!!! note
- To try out the Tenant Management REST API, refer [here]({{base_path}}/apis/tenant-management-rest-api/).
+ Please note that the search and filter feature is case-insensitive.
+
+### Basic search
+
+To simply search for a root organization by its `domain` name, enter the domain name in the search bar and press `Enter`.
+
+This will do a basic search to find the root organizations that **contain** the search term in their `domain` name.
+
+![Root Organization Search]({{base_path}}/assets/img/guides/multitenancy/root-organization-basic-search.png)
+
+### Advanced search
+
+To perform an advanced search, click on the **Filter** icon. This will open up a popup where you can search for root organizations based on the following parameters:
+
+- **Filter attribute**: Search for root organizations based on an attribute.
+
+ !!! note
+ Currently, only the `Domain` attribute is supported.
+
+- **Filter condition**: Choose an operator to perform the search.
+ - `Starts with`: Matches starting with the entered value.
+ - `Ends with`: Matches ending with the entered value.
+ - `Contains`: Matches containing the entered value.
+ - `Equals`: Matches containing exactly the entered value.
+
+- **Filter value**: Enter the search value.
+
+![Root Organization Advanced Search]({{base_path}}/assets/img/guides/multitenancy/root-organization-advanced-search.png)
diff --git a/en/identity-server/next/docs/guides/user-self-service/user-username-recovery.md b/en/identity-server/next/docs/guides/user-self-service/user-username-recovery.md
new file mode 100644
index 0000000000..8bbd718c49
--- /dev/null
+++ b/en/identity-server/next/docs/guides/user-self-service/user-username-recovery.md
@@ -0,0 +1,40 @@
+# Username recovery for users
+
+Users may recover a forgotten username from an application sign-in page by following the steps below.
+
+!!! note "Before you begin"
+
+ Administrators should [enable username recovery]({{base_path}}/guides/account-configurations/account-recovery/username-recovery/) for users of the organization.
+
+## Recover a forgotten username
+
+To recover the username, the user should follow these steps.
+
+1. Go to a login page via a business application or the [My Account portal]({{base_path}}/guides/user-self-service/customer-self-service-portal/).
+
+ ![Recover your password]({{base_path}}/assets/img/guides/organization/self-service/customer/recover-your-username.png){: width="300" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+2. Click **Forgot username?**
+
+3. Enter the information for the account you’re trying to recover, then click **Next**.
+
+ ![Username recovery claim]({{base_path}}/assets/img/guides/organization/self-service/customer/username-recovery-claim.png){: width="300" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+
+4. Select your preferred channel to receive username recovery information, then click **Next**.
+
+ ![Username recovery channel selection]({{base_path}}/assets/img/guides/organization/self-service/customer/username-recovery-channel-selection.png){: width="300" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+
+5. You can now view the username recovery information in your email or mobile, as selected in the previous step.
+
+## Check password recovery channel information
+Users can also check the email address and mobile number to which their username recovery information is sent.
+
+1. In the My Account portal, navigate to **Security** > **Account Recovery**.
+
+ ![Account recovery in {{ product_name }} MyAccount]({{base_path}}/assets/img/guides/users/account-recovery.png){: width="700" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+2. Click the eye icon of the relevant row, to check the recovery email address or the recovery mobile.
+
+3. Click **Done**.
diff --git a/en/identity-server/next/docs/guides/users/attributes/manage-attributes.md b/en/identity-server/next/docs/guides/users/attributes/manage-attributes.md
index ac60b699c1..6bef9e2325 100644
--- a/en/identity-server/next/docs/guides/users/attributes/manage-attributes.md
+++ b/en/identity-server/next/docs/guides/users/attributes/manage-attributes.md
@@ -1,2 +1 @@
-{% set attribute_path = "**User Attributes and Stores**" %}
{% include "../../../../../../includes/guides/users/attributes/manage-attributes.md" %}
\ No newline at end of file
diff --git a/en/identity-server/next/docs/guides/users/migrate-users/index.md b/en/identity-server/next/docs/guides/users/migrate-users/index.md
new file mode 100644
index 0000000000..36ccdb52c7
--- /dev/null
+++ b/en/identity-server/next/docs/guides/users/migrate-users/index.md
@@ -0,0 +1,2 @@
+{% set product_name = "WSO2 Identity Server" %}
+{% include "../../../../../../includes/guides/users/migrate-users/index.md" %}
diff --git a/en/identity-server/next/docs/guides/users/migrate-users/migrate-passwords.md b/en/identity-server/next/docs/guides/users/migrate-users/migrate-passwords.md
new file mode 100644
index 0000000000..1981fc3ef6
--- /dev/null
+++ b/en/identity-server/next/docs/guides/users/migrate-users/migrate-passwords.md
@@ -0,0 +1,2 @@
+{% set product_name = "WSO2 Identity Server" %}
+{% include "../../../../../../includes/guides/users/migrate-users/migrate-passwords.md" %}
diff --git a/en/identity-server/next/docs/guides/users/migrate-users/migrate-users.md b/en/identity-server/next/docs/guides/users/migrate-users/migrate-users.md
new file mode 100644
index 0000000000..242d7b179e
--- /dev/null
+++ b/en/identity-server/next/docs/guides/users/migrate-users/migrate-users.md
@@ -0,0 +1,2 @@
+{% set product_name = "WSO2 Identity Server" %}
+{% include "../../../../../../includes/guides/users/migrate-users/migrate-users.md" %}
diff --git a/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-only-ldap-user-store.md b/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-only-ldap-user-store.md
index e6e7fc042f..ab424c75d4 100644
--- a/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-only-ldap-user-store.md
+++ b/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-only-ldap-user-store.md
@@ -35,6 +35,10 @@ If you are configuring a server that has not been started yet, you need to updat
- `http://wso2.org/claims/userid`
- `http://wso2.org/claims/created`
- `http://wso2.org/claims/modified`
+ - `http://wso2.org/claims/emailAddresses`
+ - `http://wso2.org/claims/verifiedAddresses`
+ - `http://wso2.org/claims/mobileNumbers`
+ - `http://wso2.org/claims/verifiedMobileNumbers`
For `created` and `modified` claims, it is recommended to use the `createTimestamp` and `modifyTimestamp`
operational attributes.
@@ -58,6 +62,10 @@ configurations.
- `http://wso2.org/claims/userid`
- `http://wso2.org/claims/created`
- `http://wso2.org/claims/modified`
+ - `http://wso2.org/claims/emailAddresses`
+ - `http://wso2.org/claims/verifiedAddresses`
+ - `http://wso2.org/claims/mobileNumbers`
+ - `http://wso2.org/claims/verifiedMobileNumbers`
Refer to the [Update Attributes]({{base_path}}/guides/users/attributes/manage-attributes/#update-attributes)
to learn more on updating attribute mappings. For `created` and `modified` attributes, it is recommended to use the
@@ -65,6 +73,8 @@ configurations.
For `username` and `userid` claims, the `Username Attribute` and `User ID Attribute` properties configured in the User Store configuration should be used to ensure proper user authentication.
+ Ensure that multiple email addresses and mobile numbers attributes are properly configured by following the instructions in the [Assign multiple email addresses and mobile numbers to a user]({{base_path}}/guides/users/attributes/manage-attributes/#assign-multiple-email-addresses-and-mobile-numbers-to-a-user) section.
+
!!! Warning
If you have more than one tenant, you need to change the attributes mappings for each tenant before adding the
new configurations to the `deployment.toml` file.
diff --git a/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-active-directory-user-store.md b/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-active-directory-user-store.md
index 72854ec8fb..6c31d12e9e 100644
--- a/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-active-directory-user-store.md
+++ b/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-active-directory-user-store.md
@@ -54,6 +54,10 @@ If you are configuring a server that has not been started yet, you need to updat
- `http://wso2.org/claims/userid`
- `http://wso2.org/claims/created`
- `http://wso2.org/claims/modified`
+ - `http://wso2.org/claims/emailAddresses`
+ - `http://wso2.org/claims/verifiedAddresses`
+ - `http://wso2.org/claims/mobileNumbers`
+ - `http://wso2.org/claims/verifiedMobileNumbers`
For `created` and `modified` claims, it is recommended to use the `whenCreated` and `whenChanged`
operational attributes.
@@ -77,6 +81,10 @@ configurations.
- `http://wso2.org/claims/userid`
- `http://wso2.org/claims/created`
- `http://wso2.org/claims/modified`
+ - `http://wso2.org/claims/emailAddresses`
+ - `http://wso2.org/claims/verifiedAddresses`
+ - `http://wso2.org/claims/mobileNumbers`
+ - `http://wso2.org/claims/verifiedMobileNumbers`
Refer to the [Update Attributes]({{base_path}}/guides/users/attributes/manage-attributes/#update-attributes)
to learn more on updating attribute mappings. For `created` and `modified` claims, it is recommended to use the
@@ -84,6 +92,8 @@ configurations.
For `username` and `userid` claims, the `Username Attribute` and `User ID Attribute` properties configured in the User Store configuration should be used to ensure proper user authentication.
+ Ensure that multiple email addresses and mobile numbers attributes are properly configured by following the instructions in the [Assign multiple email addresses and mobile numbers to a user]({{base_path}}/guides/users/attributes/manage-attributes/#assign-multiple-email-addresses-and-mobile-numbers-to-a-user) section.
+
!!! Warning
If you have more than one tenant, you need to change the claim mappings for each tenant before adding the
new configurations to the `deployment.toml` file.
diff --git a/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-ldap-user-store.md b/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-ldap-user-store.md
index 8a953b07ef..1f67612e0a 100644
--- a/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-ldap-user-store.md
+++ b/en/identity-server/next/docs/guides/users/user-stores/primary-user-store/configure-a-read-write-ldap-user-store.md
@@ -37,6 +37,10 @@ If you are configuring a server that has not been started yet, you need to updat
- `http://wso2.org/claims/userid`
- `http://wso2.org/claims/created`
- `http://wso2.org/claims/modified`
+ - `http://wso2.org/claims/emailAddresses`
+ - `http://wso2.org/claims/verifiedAddresses`
+ - `http://wso2.org/claims/mobileNumbers`
+ - `http://wso2.org/claims/verifiedMobileNumbers`
For `created` and `modified` claims, it is recommended to use the `createTimestamp` and `modifyTimestamp`
operational attributes.
@@ -60,6 +64,10 @@ configurations.
- `http://wso2.org/claims/userid`
- `http://wso2.org/claims/created`
- `http://wso2.org/claims/modified`
+ - `http://wso2.org/claims/emailAddresses`
+ - `http://wso2.org/claims/verifiedAddresses`
+ - `http://wso2.org/claims/mobileNumbers`
+ - `http://wso2.org/claims/verifiedMobileNumbers`
Refer to the [Update Attributes]({{base_path}}/guides/users/attributes/manage-attributes/#update-attributes)
to learn more on updating attribute mappings. For `created` and `modified` claims, it is recommended to use the
@@ -67,6 +75,8 @@ configurations.
For `username` and `userid` claims, the `Username Attribute` and `User ID Attribute` properties configured in the User Store configuration should be used to ensure proper user authentication.
+ Ensure that multiple email addresses and mobile numbers attributes are properly configured by following the instructions in the [Assign multiple email addresses and mobile numbers to a user]({{base_path}}/guides/users/attributes/manage-attributes/#assign-multiple-email-addresses-and-mobile-numbers-to-a-user) section.
+
!!! Warning
If you have more than one tenant, you need to change the claim mappings for each tenant before adding the
new configurations to the `deployment.toml` file.
diff --git a/en/identity-server/next/docs/guides/your-is/recover-username.md b/en/identity-server/next/docs/guides/your-is/recover-username.md
new file mode 100644
index 0000000000..2763fb8c1b
--- /dev/null
+++ b/en/identity-server/next/docs/guides/your-is/recover-username.md
@@ -0,0 +1,23 @@
+# Recover your username
+
+If you are the owner or an administrator of a WSO2 Identity Server organization, the following guide explains how you can recover a forgotten username.
+
+To recover your username:
+
+1. Go to the sign-in page of the [My Account Portal]({{base_path}}/guides/your-is/is-self-service/#access-my-account-portal).
+
+ ![Recover your username]({{base_path}}/assets/img/guides/organization/self-service/customer/recover-your-username.png){: width="300" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+2. Click **Forgot username?**.
+
+3. Enter the information for the account you’re trying to recover, then click **Next**.
+
+ ![Username recovery claim]({{base_path}}/assets/img/guides/organization/self-service/customer/username-recovery-claim.png){: width="300" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+
+4. Select your preferred channel to receive username recovery information, then click **Next**.
+
+ ![Username recovery channel selection]({{base_path}}/assets/img/guides/organization/self-service/customer/username-recovery-channel-selection.png){: width="300" style="display: block; margin: 0; border: 0.3px solid lightgrey;"}
+
+
+5. You can now view the username recovery information in your email or mobile, as selected in the previous step.
diff --git a/en/identity-server/next/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml b/en/identity-server/next/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml
index c00ee47ba6..d81e4d931c 100644
--- a/en/identity-server/next/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml
+++ b/en/identity-server/next/docs/references/actions/pre-issue-access-token-action/api/pre-issue-access-token-action-v1.yaml
@@ -30,15 +30,26 @@ paths:
content:
application/json:
schema:
- $ref: '#/components/schemas/SuccessResponse'
- example:
- - actionStatus: SUCCESS
- operations:
- - op: add
- path: /accessToken/claims/-
- value:
- name: customSID
- value: "12345"
+ oneOf:
+ - $ref: '#/components/schemas/SuccessResponse'
+ - $ref: '#/components/schemas/FailedResponse'
+ examples:
+ successExample:
+ summary: Success response
+ value:
+ actionStatus: SUCCESS
+ operations:
+ - op: add
+ path: /accessToken/claims/-
+ value:
+ name: customSID
+ value: "12345"
+ failedExample:
+ summary: Failed response
+ value:
+ actionStatus: FAILED
+ failureReason: invalid_scope
+ failureDescription: "The requested scope is invalid, unknown, or malformed."
"400":
description: Bad Request
content:
@@ -47,7 +58,7 @@ paths:
$ref: '#/components/schemas/ErrorResponse'
example:
- actionStatus: ERROR
- error: invalid_request
+ errorMessage: invalid_request
errorDescription: SID claim is missing
"500":
description: Server Error
@@ -57,7 +68,7 @@ paths:
$ref: '#/components/schemas/ErrorResponse'
example:
- actionStatus: ERROR
- error: server_error
+ errorMessage: server_error
errorDescription: Failed to process the response
components:
schemas:
@@ -288,6 +299,20 @@ components:
items:
$ref: '#/components/schemas/Operations'
description: Defines the success response.
+ FailedResponse:
+ type: object
+ properties:
+ actionStatus:
+ type: string
+ enum:
+ - FAILED
+ description: Indicates the outcome of the request. For a failed operation, this should be set to FAILED.
+ failureReason:
+ type: string
+ description: Provides the reason for failing to issue an access token.
+ failureDescription:
+ type: string
+ description: Offers a detailed explanation of the failure.
ErrorResponse:
type: object
properties:
@@ -296,16 +321,14 @@ components:
enum:
- ERROR
description: Indicates the outcome of the request. For an error operation, this should be set to ERROR.
- error:
+ errorMessage:
type: string
- description: The error code, as specified in OAuth 2.0 error response definitions.
+ description: The cause of the error.
errorDescription:
type: string
description: A detailed description of the error.
description: |
- When the external service responds with an ERROR state, it can return an HTTP status code of 400, 401, or 500, indicating that the expected validations are not met or there is an issue processing the request.
-
- If the defined error response is not received, or if the external service fails to respond, this is identified as an error in executing the action. In such cases, the flow will proceed as if the action was not applied, ensuring that the process continues without disruption.
+ When the external service responds with an ERROR state, it can return an HTTP status code of 400, 401, or 500, indicating either a validation failure or an issue processing the request.
RequestBody:
type: object
properties:
diff --git a/en/identity-server/next/docs/references/tutorials/configure-choreo-for-password-migration.md b/en/identity-server/next/docs/references/tutorials/configure-choreo-for-password-migration.md
new file mode 100644
index 0000000000..209912615e
--- /dev/null
+++ b/en/identity-server/next/docs/references/tutorials/configure-choreo-for-password-migration.md
@@ -0,0 +1,16 @@
+# Configure External Authentication Service for On-demand Silent Password Migration with Choreo
+
+{{ product_name }} supports on-demand silent password migration, where a migrated user's password can be seamlessly migrated to {{ product_name }} on-the-fly without forcing the user to reset the password. This involves configuring an external authentication service that communicates with the legacy IdP to authenticate users. This guide explains how you can configure the external authentication service in WSO2's integration platform, [Choreo](https://wso2.com/choreo/){target="_blank"}.
+
+!!! note
+ Learn more on [on-demand silent password migration]({{base_path}}/guides/users/migrate-users/migrate-passwords/).
+
+### Prerequisites
+
+Before you begin, ensure the following are fulfilled.
+
+- Ensure your legacy IdP provides means to perform basic user authentication (i.e. username and password authentication). For example, a SCIM2/Me REST API endpoint that could be authenticated with username and password.
+- You need to have a Github repository to host the authentication service.
+- Download [Ballerina](https://ballerina.io/downloads/){target="_blank"}, the programming language used to define the external authentication service.
+
+{% include "../../../../../includes/guides/fragments/migrate-users/configure-choreo-for-password-migration.md" %}
diff --git a/en/identity-server/next/mkdocs.yml b/en/identity-server/next/mkdocs.yml
index c6cce45397..2e3366785f 100644
--- a/en/identity-server/next/mkdocs.yml
+++ b/en/identity-server/next/mkdocs.yml
@@ -24,7 +24,12 @@ extra:
is_version: next
plugins:
- - search
+ - search:
+ indexing: "full"
+ separator: "[^\\w._]+"
+ lang: ['en']
+ prebuild_index: true
+ ngram_length: 3
- markdownextradata: {}
- include-markdown
- redirects:
@@ -214,7 +219,6 @@ plugins:
'deploy/change-to-oracle-rac.md': 'deploy/configure/databases/carbon-database/change-to-oracle-rac.md'
'deploy/change-to-postgresql.md': 'deploy/configure/databases/carbon-database/change-to-postgresql.md'
'deploy/change-to-remote-h2.md': 'deploy/configure/databases/carbon-database/change-to-remote-h2.md'
- 'deploy/change-datasource-bpsds.md': 'deploy/configure/databases/carbon-database/change-datasource-bpsds.md'
'deploy/change-datasource-consent-management.md': 'deploy/configure/databases/carbon-database/change-datasource-consent-management.md'
'deploy/enable-fips-for-is.md': 'deploy/security/enable-fips-for-is.md'
@@ -325,6 +329,7 @@ plugins:
# To address the broken links in the API Authorization guides due to the directory structure mismatch is Asgardeo and IS
'guides/api-authorization.md': 'guides/authorization/api-authorization/api-authorization.md'
+ 'guides/authorization/impersonation/user-impersonation.md': 'guides/authorization/user-impersonation.md'
# Navigation
nav:
@@ -438,6 +443,7 @@ nav:
- MFA based on ELK-risk: guides/authentication/conditional-auth/elk-risk-based-template.md
- MFA based on TypingDNA: guides/authentication/conditional-auth/typingdna-based-adaptive-auth.md
- Add passkey progressive enrollment: guides/authentication/conditional-auth/passkey-progressive-enrollment-based-template.md
+ - Add on-demand silent password migration: guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md
- Write a custom authentication script: guides/authentication/conditional-auth/write-your-first-script.md
- Configure multi-attribute login: guides/authentication/multi-attribute-login.md
- App-native authentication:
@@ -474,8 +480,7 @@ nav:
- Attribute-based access control: guides/authorization/api-authorization/attribute-based-access-control.md
- Fine-grained authorization:
- XACML in provisioning flows: guides/authorization/fine-grained-authorization/rule-based-provisioning.md
- - Impersonation:
- - User Impersonation: guides/authorization/impersonation/user-impersonation.md
+ - User Impersonation: guides/authorization/user-impersonation.md
- Identity Verification:
- Identity Verification: guides/identity-verification/index.md
- Configure an Identity Verification Provider: guides/identity-verification/configure-identity-verification-provider.md
@@ -532,6 +537,10 @@ nav:
- Properties used in read-write LDAP user store manager: guides/users/user-stores/user-store-properties/properties-read-write-ldap-user-store.md
- Configure user stores for SCIM 2.0: guides/users/user-stores/configure-user-stores-for-scim2.md
- Configure Active Directory user stores for SCIM 2.0: guides/users/user-stores/configure-active-directory-user-stores-for-scim2.md
+ - Migrate users to WSO2 Identity Server:
+ - Migrate users to WSO2 Identity Server: guides/users/migrate-users/index.md
+ - Migrate user accounts: guides/users/migrate-users/migrate-users.md
+ - Migrate user passwords: guides/users/migrate-users/migrate-passwords.md
- Account configurations:
- Account configurations: guides/account-configurations/index.md
- Login security:
@@ -560,6 +569,7 @@ nav:
- Account confirmation for self-register: guides/user-self-service/account-confirmation-for-self-register.md
- Register passkeys: guides/user-self-service/register-passkey.md
- Password recovery: guides/user-self-service/user-password-recovery.md
+ - Username recovery: guides/user-self-service/user-username-recovery.md
- Enroll TOTP: guides/user-self-service/enable-totp.md
- Manage backup codes: guides/user-self-service/manage-backup-codes.md
- Discover applications: guides/user-self-service/discover-applications.md
@@ -603,9 +613,10 @@ nav:
- Manage Console access: guides/your-is/manage-console-access.md
- Self-service: guides/your-is/is-self-service.md
- Recover your password: guides/your-is/recover-password.md
+ - Recover your username: guides/your-is/recover-username.md
- Multitenancy:
- Multitenancy: guides/multitenancy/index.md
- - Manage tenants: guides/multitenancy/manage-tenants.md
+ - Manage Root Organizations (Tenants): guides/multitenancy/manage-tenants.md
- Tenant loading policy: guides/multitenancy/configure-the-tenant-loading-policy.md
- Setup:
- Install:
@@ -631,7 +642,6 @@ nav:
- Change to Oracle RAC: deploy/configure/databases/carbon-database/change-to-oracle-rac.md
- Change to PostgreSQL: deploy/configure/databases/carbon-database/change-to-postgresql.md
- Change to remote H2: deploy/configure/databases/carbon-database/change-to-remote-h2.md
- - Change the Default Datasource for BPS: deploy/configure/databases/carbon-database/change-datasource-bpsds.md
- Change the Default Datasource for Consent Management: deploy/configure/databases/carbon-database/change-datasource-consent-management.md
- Change the Default Datasource for Session Data: deploy/configure/databases/carbon-database/change-datasource-session.md
- Data Dictionary:
@@ -681,7 +691,6 @@ nav:
- Encryption:
- Symmetric encryption:
- Symmetric encryption: deploy/security/symmetric-encryption/index.md
- - Configure symmetric key encryption: deploy/security/symmetric-encryption/use-symmetric-encryption.md
- Symmetric data encryption key rotation: deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
- Asymmetric encryption:
- Asymmetric encryption: deploy/security/asymmetric-encryption/index.md
@@ -896,6 +905,7 @@ nav:
- Verifiable credentials with Microsoft Entra Verified ID: references/tutorials/connect-with-ms-entra.md
- Verifiable credentials with MATTR: references/tutorials/connect-with-mattr.md
- Send notifications through an external scheduled task: references/tutorials/send-notification-external-schedular.md
+ - Configure Choreo for silent password migration: references/tutorials/configure-choreo-for-password-migration.md
- IAM concepts:
- OAuth2 grant types: references/grant-types.md
- OAuth2 Pushed Authorization Requests: references/pushed-authorization-requests.md
diff --git a/en/includes/concepts/add-login.md b/en/includes/concepts/add-login.md
index ac73f717bb..dece7a3a2d 100644
--- a/en/includes/concepts/add-login.md
+++ b/en/includes/concepts/add-login.md
@@ -15,9 +15,9 @@ You also need to consider enabling sign-up and sign-in options through popular s
## Add user login
-Add user login to your application by simply integrating the right Asgardeo SDK as per your application development technology. Asgardeo SDKs provide you with the necessary components and utilities to easily add user login into your application, manage tokens and maintain authentication state.
+Add user login to your application by simply integrating the right {{product_name}} SDK as per your application development technology. {{product_name}} SDKs provide you with the necessary components and utilities to easily add user login into your application, manage tokens and maintain authentication state.
-Behind the scenes, Asgardeo SDKs use the OpenID Connect protocol to handle login requests with Asgardeo. When a user attempts to log in, they are redirected to Asgardeo for login. Once the user is authenticated, the application receives an OpenID Connect ID token, which includes the user's information and metadata. Asgardeo SDKs simplify the complexities of OpenID request-response flows and token processing, and enable security best practices such as token validation and the PKCE extension by default.
+Behind the scenes, {{product_name}} SDKs use the OpenID Connect protocol to handle login requests with {{product_name}}. When a user attempts to log in, they are redirected to {{product_name}} for login. Once the user is authenticated, the application receives an OpenID Connect ID token, which includes the user's information and metadata. {{product_name}} SDKs simplify the complexities of OpenID request-response flows and token processing, and enable security best practices such as token validation and the PKCE extension by default.
![Asgardeo SDK]({{base_path}}/assets/img/concepts/asgardeo-sdk.png){: width="700"}
@@ -25,12 +25,12 @@ Explore all the supported application development technologies, SDKs and quick s
!!! tip
- - By default, Asgardeo SDKs redirect users to Asgardeo using HTTP redirects. However, if you prefer to create your own login screen within the application, you can still integrate Asgardeo for user login using the Asgardeo Login API.
+ - By default, {{product_name}} SDKs redirect users to {{product_name}} using HTTP redirects. However, if you prefer to create your own login screen within the application, you can still integrate {{product_name}} for user login using the {{product_name}} Login API.
- - In addition to OpenID Connect, you can also use SAML 2.0 to integrate your application with Asgardeo for user login.
+ - In addition to OpenID Connect, you can also use SAML 2.0 to integrate your application with {{product_name}} for user login.
-Asgardeo automatically configures a default login flow for you to get started. You can design your desired login flow by adding social providers or MFA options using Asgardeo's visual login flow designer, where you can drag and drop the required elements.
+{{product_name}} automatically configures a default login flow for you to get started. You can design your desired login flow by adding social providers or MFA options using {{product_name}}'s visual login flow designer, where you can drag and drop the required elements.
![Add login flow]({{base_path}}/assets/img/concepts/login-flow.png)
@@ -41,17 +41,17 @@ Alternatively, you can use the Login Flow AI feature to generate the desired log
## On-board users
-Allow users to self-onboard to your application, either directly or via social and partner platforms. You can utilize customizable user onboarding portal components from Asgardeo, or use Asgardeo's user onboarding APIs. Additionally, connect existing on-premise AD and LDAP user directories using the remote user store agent.
+Allow users to self-onboard to your application, either directly or via social and partner platforms. You can utilize customizable user onboarding portal components from {{product_name}}, or use {{product_name}}'s user onboarding APIs. Additionally, connect existing on-premise AD and LDAP user directories using the remote user store agent.
![Onboard users]({{base_path}}/assets/img/concepts/asgardeo-user-stores.png)
-Asgardeo offers a user self-onboarding portal component that can be seamlessly integrated with your applications and allows you to customize the onboarding experience and branding. For greater flexibility and control, you can use the Asgardeo user onboarding API to integrate with your application's specific onboarding workflows.
+{{product_name}} offers a user self-onboarding portal component that can be seamlessly integrated with your applications and allows you to customize the onboarding experience and branding. For greater flexibility and control, you can use the {{product_name}} user onboarding API to integrate with your application's specific onboarding workflows.
## Add self-care account management features
-Let your users self-manage their profiles, protect their accounts, and handle recovery on their own. Asgardeo offers all the required self-management features for your application out-of-the-box. Your application can be integrated with Asgardeo user self-care portal components with your own branding. Alternatively, you can integrate Asgardeo’s self-management capabilities using the self-care user API to offer app-native experience.
+Let your users self-manage their profiles, protect their accounts, and handle recovery on their own. {{product_name}} offers all the required self-management features for your application out-of-the-box. Your application can be integrated with {{product_name}} user self-care portal components with your own branding. Alternatively, you can integrate {{product_name}}’s self-management capabilities using the self-care user API to offer app-native experience.
Add self-manage features for your application users to:
@@ -66,7 +66,7 @@ Add self-manage features for your application users to:
- export their user profile
-Protect your application, data and users by enabling security controllers offered by Asgardeo:
+Protect your application, data and users by enabling security controllers offered by {{product_name}}:
- conditionally enforcing MFA
- enabling password policies
diff --git a/en/includes/concepts/api-security.md b/en/includes/concepts/api-security.md
new file mode 100644
index 0000000000..f33b7f4b8b
--- /dev/null
+++ b/en/includes/concepts/api-security.md
@@ -0,0 +1,58 @@
+# API security
+
+
+The business APIs you deploy, whether used by your internal applications or external partners, must be properly secured and managed. Implementing robust API security is crucial for several reasons. It safeguards sensitive data transmitted via APIs, preventing unauthorized access while ensuring legitimate users have the correct level of access. Moreover, strong API security is vital for maintaining a business’s reputation and customer trust. A single data breach can significantly harm your brand name and erode customer confidence, so preventing cybersecurity incidents not only helps avoid negative media attention but also shows a commitment to protecting user data and privacy. Furthermore, API security ensures compliance with industry-specific regulations such as HIPAA and FAPI.
+
+{{product_name}} can secure your APIs and make sure only authorized applications and authorized users can access the APIs. {{product_name}} can be integrated with your APIs in two approaches:
+
+- **Security Token Service and Authorization Provider** – You can integrate with API gateways such as Azure, AWS, or any OpenID Connect-supported gateway. {{product_name}} will provide OAuth2-based Security Token Service and API authorization based on RBAC (Role-Based Access Control). This option is particularly useful if you are developing and hosting your own APIs without using an API gateway, as you only need to verify the tokens issued by {{product_name}}.
+
+- **OAuth2 Token Service Provider** – You can also integrate {{product_name}} as an Identity Provider (IdP) with existing API management solutions such as WSO2 API Manager, Choreo API Management, or any API management platform that supports OpenID Connect IdP integration. In this scenario, {{product_name}} offers OAuth2-based Security Token Service, while your API management solution handles API authorization. This is the preferred option when you want to use platform-level customer identity or workforce identity provider with all your applications and APIs.
+
+## Define and secure API resources
+
+Define your API resources and associated permissions as scopes in {{product_name}} using the console or API, and attach the authorization policies.
+
+!!! note
+
+ Learn more about [supported Authorization policies for APIs and apps]({{base_path}}/references/authorization-policies-for-apps/)
+
+[Define an API using {{product_name}} console]({{base_path}}/guides/authorization/api-authorization/api-authorization/#register-a-business-api)
+
+ [Diagram - An API and scope]
+
+## Authorize applications to use APIs
+
+[Authorize applications to consume API resources]({{base_path}}/guides/authorization/api-authorization/api-authorization/#authorize-apps-to-consume-api-resources) and define their access level by assigning a set of scopes.
+
+!!! tip
+
+ If your application needs FAPI compliance for API access, {{product_name}} simplifies the process with a one-click, FAPI-compliant option. This feature ensures that all necessary security configurations for FAPI compliance are automatically applied to your app. Learn more about [FAPI-compliant apps]({{base_path}}/guides/applications/register-a-fapi-compliant-app/).
+
+
+Define application level roles as per your business requirements and assign selected scopes from the previous step. You can create both application-level roles and organizational-level roles. These roles can be assigned to users and user groups so that their access to the API is restricted based on roles.
+
+
+[Define application-level roles]({{base_path}}/guides/authorization/api-authorization/api-authorization/#create-roles-and-assign-users) based on your business needs, and assign relevant scopes that you selected in the previous step. You can create both application-specific roles and organization-wide roles, which can be applied to users or user groups to ensure access to APIs is restricted and managed according to roles.
+
+## Simplify token generation and verification
+
+Use {{product_name}} SDKs for your preferred web application framework to request access tokens while also managing user sign-ins. {{product_name}} SDKs allow you to request specific scopes, representing different access levels within the APIs. {{product_name}} applies authorization policies to each token request, ensuring that applications only receive the scopes authorized for the current user and app. The SDKs also handle token verification complexities, so you won’t need to write additional code for token processing and verification.
+Explore the full range of SDKs supported by {{product_name}}.
+
+Alternatively, you can use any OAuth2/OIDC framework to create token requests and manage tokens on your own.
+
+You can use one of the following methods to verify tokens during the token verification process, typically done at the API gateway level or within the API implementation if no gateway is used:
+
+- **Signature Verification** - Verify the token's signature and validity directly. {{product_name}} provides a JWKS (JSON Web Key Set) endpoint, allowing you to retrieve the public key associated with the private key used for signing. This method doesn't require additional network calls to {{product_name}}, ensuring optimal performance.
+- **Token Introspection** - Verify the token's validity and gain additional token details by calling {{product_name}}'s introspection endpoint. While this approach involves extra network calls, it offers additional security, such as checking whether the token has been revoked.
+
+If you are using an API management solution that provides API authorization along with other management capabilities, you can easily integrate {{product_name}} as an identity provider for token generation. This is a common approach when you want to leverage {{product_name}} as the customer or workforce identity provider across applications and APIs.
+
+- [Integrate {{product_name}} with WSO2 APK](https://apk.docs.wso2.com/en/latest/setup/identity-platform/idp/asgardeo-idp/){: target="_blank"}
+- [Choreo API Management](https://wso2.com/choreo/docs/administer/configure-an-external-idp/configure-asgardeo-as-an-external-idp/){: target="_blank"}
+
+
+
+
+
diff --git a/en/includes/concepts/customer-iam.md b/en/includes/concepts/customer-iam.md
new file mode 100644
index 0000000000..d585b665b1
--- /dev/null
+++ b/en/includes/concepts/customer-iam.md
@@ -0,0 +1,89 @@
+# Onboard Business customers, delegate administration and customize login
+
+It is a common and critical requirement to develop applications that serve business customers and partners, and ultimately enable you to cater to their (consumer) customer bases too. In some cases, rather than business customers and partners, the application may need to accommodate multiple business units or groups of related organizations. These types of applications are generally known as B2B (business-to-business) applications, and the B2B model is particularly prevalent in cloud-based Software as a Service (SaaS) businesses.
+
+## Overview
+
+B2B identity specifically addresses use cases associated with B2B applications, such as onboarding and managing business customers and partners (also referred to as organization management), delegated administration, and providing custom login flows for the end-users of business customers and partners.
+
+Use of the right B2B identity capabilities offers significant advantages, including:
+
+- **Efficient business customer onboarding** - Manual and ad-hoc onboarding methods slow down the process, causing delays and missed business opportunities. B2B identity solutions streamline onboarding through automation and APIs, enabling self-onboarding or administrative control, fostering smoother engagement with customers and partners.
+
+- **Delegated control** - Managing staff accounts for customers and partners places a burden on IT teams, requiring continuous provisioning and deprovisioning, and also leads into administrative overhead . B2B identity solutions offer delegated administration, allowing partner administrators to handle user management and their access control reducing IT support overhead.
+
+- **Frictionless user experiences** - Duplicate accounts and separate credential creation for end users from business customers and partners, complicating the user experience and damaging brand loyalty. B2B identity solutions enable partners to integrate their customer identity providers and customize login flows as per their security expectations.
+
+- **Return of Investment (RoI)** - Manual processes increase operational expenses due to the need for additional IT support. B2B identity solutions improve ROI by automating processes, minimizing administrative tasks, and stabilizing costs as the business grows, enabling investment in growth-focused initiatives.
+
+- **Risk Management** - Relying on manual processes introduces security vulnerabilities and privacy risks, such as managing multiple credentials and user accounts. B2B identity solutions reduce risks through automated onboarding, end-to-end auditing, and letting business customers and partners to bring their own customer and employed identity providers (IdPs)
+
+## On-board business customers and partners
+
+Just as you allow your B2C consumers to self-sign up for your application, you can extend the same capability to business customers and partners. Achieve this by integrating {{product_name}} Organization APIs into your business customer and partner-facing applications, whether developed in-house or using bespoke solutions like CMS or ERP systems. {{product_name}} provides flexibility to map any complex business organization with complex hierarchies and manage their interactions and bounders.
+
+!!! tip
+
+ Download and explore the Postman collection to better understand how to integrate [{{product_name}} Organization APIs]({{base_path}}/apis/organization-apis/) with your application.
+
+In cases where you need more control over the onboarding process and prefer to initiate it yourself, you can integrate [{{product_name}} organization APIs]({{base_path}}/apis/organization-apis/) with your existing business customer and partner management applications.
+
+If you don’t have dedicated onboarding applications to integrate with [{{product_name}} Organization APIs]({{base_path}}/apis/organization-apis/), you can simply use the {{product_name}} console to initiate the onboarding process and invite your business customers and partners.
+
+## Delegate administrative tasks
+
+Delegate and let business customers and partners on-board their staff members, manage their access in your applications, on-board their customer identity providers (IdPs) and customize the login experience to meet their own security requirements.
+
+- Enable business customers and partners to onboard their staff
+ - Create user accounts for their staff
+ - Invite staff to setup user accounts
+ - Plug employee-IdP
+
+- Enable business customers and partners to manage their stuff as user groups
+
+- Enable business customers and partners to assign roles to their staff and manage their access in your B2B application
+
+## On-board consumers from business customers and define their experience
+
+Enable business customers and partners to plug their customer-IdPs to enable friction-less login experience for their customers (consumers) accessing your applications. Consumers can be on-boarded to match with your organizational business structure.
+
+
+
+
+Manage staff and consumers of each organization at their own organizational level, ensuring fully isolated user onboarding and management experience. Ideal for organization with business customers and partners. Organizations can be provided the flexibility to onboard their own business customers and partners forming a hierarchical business ecosystem.
+
+[ Diagram]
+
+
+
+
+Manage all the staff and customers centrally at the root-organization level and assign them to sub-organizations with different roles and access based on business needs. This approach is ideal for representing entities within the same corporate group or divisions of a larger organization. Organizations can be represented hierarchically to represent complex organizational structures.
+
+[Diagram]
+
+
+
+
+
+!!! tip
+
+ Depending on your requirement you can have a mixture of both strategies allowing you represent complex organizational hierarchies.
+
+- Let business customers and partners customize and define login experience for their customers using visual login flow editor and enable MFA to secure user accounts.
+
+- Let business customers and partners rebrand all human-touch points with their own brandings.
+
+ - Rebrand user sign-up and sign-in screens
+ - Rebrand MFA screens such as SMS/EMail OTP and TOTP.
+ - Rebrand account management password reset and recovery interfaces
+ - Customize EMail templates
+ - My account portal
+
+- Let business customers and partners enable their customers to access what user profile information are stored by you and manage them by leveraging self-care my account portal and integrating my account API with their own applications.
+
+
+
+
+
+
+
diff --git a/en/includes/concepts/workforce-iam.md b/en/includes/concepts/workforce-iam.md
new file mode 100644
index 0000000000..3bb63b5ef6
--- /dev/null
+++ b/en/includes/concepts/workforce-iam.md
@@ -0,0 +1,75 @@
+# Manage employees, their access and SSO
+
+Whether you are a large enterprise, startup, or medium-sized business, one of the key software components you need to invest in is an employee identity solution. This system helps you efficiently provision and deprovision users, while managing their access across your organization. Too relaxed employee identity practices increase both security and business risks, while overly strict employee identity practices can lead to inefficiencies and frustration among staff. Therefore, it is important to choose an employee identity solution that aligns with your security requirements and increase productivity. A well-implemented identity solution offers several benefits, including:
+
+- **Improved Efficiency and Productivity** - Employee identity solutions improve efficiency and productivity by automating user provisioning and deprovisioning, ensuring that staff members have the correct system access without the need for manual intervention. Enterprise Single-Sign-On (SSO) allows seamless access to multiple applications, both on-premise and cloud-based, without the need to relogin. Additionally, the group and role-based capabilities make it easier to manage access based on job roles.
+
+- **Enhanced Security** - Employee identity solutions enhance security by offering advanced authentication methods like security keys, passkeys, and push notifications. Risk-based adaptive authentication evaluates access based on factors like location, device, and behavior, while access control limits permissions to what's necessary for job duties. Automated provisioning and deprovisioning ensure prompt removal of access when employees leave or change roles, also helping enforce security policies
+
+- **Cost Reduction** - Adopting an employee identity solution leads to significant cost reductions by reducing administrative burdens. These solutions save valuable time and resources by minimizing tedious tasks such as manual password resets and manual registration of security devices. By consolidating user accounts and access management, organizations can eliminate or reduce expenses associated with managing identities across multiple applications
+
+- **Improved Compliance** - Employee identity solutions play a crucial role in maintaining regulatory compliance. They provide organizations with control over access rights, helping meet various data protection and privacy regulations such as GDPR. Centralized management of user identities and access enables better transparency in security policies, configurations, and privileges, ensuring that organizations can effectively uphold compliance standards.
+
+## On-board workforce, provisioning them to systems and manage access
+
+Automate and create unified onboarding experiences for your workforce by integrating various on-boarding channels such as HRM systems, existing AD and LDAP directories with {{product_name}} to create a unified view of your workforce that enables centralized workforce management. Different provisioning and deprovisioning policies can be implanted as per workforce variance based on their employment such as full-time, contractual and outsourced and based on their job roles.
+
+- Use SCIM 2.0 industry standard to provision and deprovision workforce user accounts
+
+- Use {{product_name}} console to create and invite workforce users
+
+- Define and manage workforce access to your business applications using roles and user groups available with [{{product_name}} RBAC]({{base_path}}/guides/authorization/api-authorization/api-authorization/).
+
+## Secure workforce and business with strong authentication
+
+Secure user accounts of your workforce and business applications by enforcing MFA options. {{product_name}} offers secure MFA options including SMS and Email OTP, TOTP using authenticator apps, FIDO-based Passkeys, Duo-based push notifications and hardware tokens and facial biometrics such as iProove.
+
+Get rid of passwords completely and offer secure passwordless authentication for your workforce using Magic Link, Passkeys, biometrics and Email/SMS OTPs.
+
+- Configure Email OTP for your workforce
+- Configure SMS OTP for your workforce
+- Configure TOTP for your workforce
+- Configure Passkey for your workforce
+- Configure Magic Link for your workforce
+- Configure Duo push notifications and hardware tokens for your workforce
+- Configure iProove facial biometrics for your workforce
+- Configure HYPR biometric for your workforce
+
+{{product_name}} automatically configures a default login flow for you to get started. You can design your desired login flow by adding social providers or MFA options using {{product_name}}'s visual login flow designer, where you can drag and drop the required elements. Alternatively, you can use the Login Flow AI feature to generate the desired login flow based on your plain text instructions.
+
+Make workforce authentication adaptive by adjusting authentication options such as adaptive MFA , adaptive access control and passkey enrollment as per the current risk level assessed using contextual parameters such as location, device and behavior. {{product_name}} offers a set of ready to use templates that can be configured for your workforce requirements and you can also develop your own adaptive authentication scripts.
+
+- Configure group-based access control
+- Configure concurrent sessions based access control
+- Configure MFA based on user sign-in option
+- Configure MFA based on user device
+- Configure MFA based on user group
+- Configure MFA based on IP address
+- Configure progressive passkey enrolment
+- Write your own adaptive authentication script
+
+## Provide Single-Sign-On (SSO) across your application
+
+Make your workforce experience frictionless and efficient when accessing the cloud-based and on-premise applications by enabling enterprise SSO. The SSO templates provided by {{product_name}} make it easy for you to integrate with cloud applications.
+
+- Configure SSO for Office365
+- Configure SSO for Google Workspace
+- Configure SSO for Salesforce
+- Configure SSO for OpenID Connect supported applications
+- Configure SSO for SAML 2.0 supported applications
+
+## Enable self-care account management capabilities for your workforce
+
+Let your workforce manage their profiles, protect their accounts, and handle recovery on their own. {{product_name}} offers all the required self-management features for your application out of the box, your application can be integrated with {{product_name}} user self-care portal components with your own branding.
+
+Add self-manage features for your application users:
+
+- Allow users to update their user profiles
+- Allow users to update their passwords
+- Allow users to recover forgotten password
+- Allow users to login with multiple login identifies
+- Allow users to associate social accounts
+- Allow users to enable MFA
+- Allow users to enroll passkeys
+- Allow users to review consents
+- Allow users to export their user profile
\ No newline at end of file
diff --git a/en/includes/guides/encryption/asymmetric-encryption.md b/en/includes/deploy/security/asymmetric-encryption/index.md
similarity index 99%
rename from en/includes/guides/encryption/asymmetric-encryption.md
rename to en/includes/deploy/security/asymmetric-encryption/index.md
index 49c9f9f149..64e395fff5 100644
--- a/en/includes/guides/encryption/asymmetric-encryption.md
+++ b/en/includes/deploy/security/asymmetric-encryption/index.md
@@ -28,4 +28,4 @@ For other types of encryption, [symmetric encryption]({{base_path}}/deploy/secur
[encryption]
internal_crypto_provider = "org.wso2.carbon.crypto.provider.KeyStoreBasedInternalCryptoProvider"
- ```
+ ```
\ No newline at end of file
diff --git a/en/includes/guides/encryption/configure-keystores.md b/en/includes/deploy/security/keystores/configure-keystores.md
similarity index 100%
rename from en/includes/guides/encryption/configure-keystores.md
rename to en/includes/deploy/security/keystores/configure-keystores.md
diff --git a/en/includes/guides/encryption/create-new-keystores.md b/en/includes/deploy/security/keystores/create-new-keystores.md
similarity index 100%
rename from en/includes/guides/encryption/create-new-keystores.md
rename to en/includes/deploy/security/keystores/create-new-keystores.md
diff --git a/en/includes/guides/encryption/index.md b/en/includes/deploy/security/keystores/index.md
similarity index 98%
rename from en/includes/guides/encryption/index.md
rename to en/includes/deploy/security/keystores/index.md
index 5c424e7c21..4864344b4b 100644
--- a/en/includes/guides/encryption/index.md
+++ b/en/includes/deploy/security/keystores/index.md
@@ -80,4 +80,4 @@ Follow the recommendations given below when you set up your keystores.
!!! info "Related topics"
- [Deploy: Create New Keystores]({{base_path}}/deploy/security/asymmetric-encryption/create-new-keystores)
- - [Deploy: Configure Keystores]({{base_path}}/deploy/security/asymmetric-encryption/configure-keystores-in-wso2-products)
+ - [Deploy: Configure Keystores]({{base_path}}/deploy/security/asymmetric-encryption/configure-keystores-in-wso2-products)
\ No newline at end of file
diff --git a/en/includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md b/en/includes/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
similarity index 100%
rename from en/includes/guides/encryption/manage-ca-signed-certificates-in-a-keystore.md
rename to en/includes/deploy/security/keystores/manage-ca-signed-certificates-in-a-keystore.md
diff --git a/en/includes/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md b/en/includes/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
new file mode 100644
index 0000000000..3bbdfe34c3
--- /dev/null
+++ b/en/includes/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation.md
@@ -0,0 +1,250 @@
+# Blue-Green Data Encryption Key Rotation
+
+This section contains the complete process you need to follow in order to perform symmetric data encryption key rotation in WSO2 Identity Sever(WSO2 IS version 5.11.0 and above).
+
+Key rotation can be defined as retiring an encryption key and replacing it with a new key. Data is encrypted using a key known as a Data Encryption Key(DEK) and the DEK is then encrypted with another key called Key Encryption Key(KEK). This is known as envelope encryption. Frequent rotations of these encryption keys are considered as an industry best practice by PCI DSS and NIST standards.
+
+## Why should you rotate encryption keys?
+
+!!! info
+ Originator Usage Period (OUP) is the time period during which encryption is applied to data.
+
+- A cryptoperiod is the time span during which a specific key is authorized for use. [NIST SP 800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf){:target="_blank"} recommends different cryptoperiods for different encryption key types.
+
+ - Symmetric Data Encryption Keys
+
+ - OUP recommended for large volumes of data is about a day or a week.
+ - OUP recommended for smaller volumes of data is about 2 years.
+
+ - Symmetric Key, Wrapping Keys
+
+ - OUP recommended for a key that wraps a large number of keys is about a day or a week.
+ - OUP recommended for a key that wraps a smaller number of keys is up to 2 years.
+
+- Security compliance requirements
+- Security breach requirements
+
+!!! note
+ The above-mentioned cryptoperiods can vary based on other factors like the sensitivity of data and the amount of data we have.
+
+## Background
+
+WSO2 Identity Server has the following key usages for signing/encrypting data and each of these types will have different key rotation requirements.
+
+- TLS Connection
+- Signing and encryption of data (JWT assertions, payloads) shared with external parties (SP, IdP).
+- Encryption of sensitive runtime level configuration secrets/user data persisted in datastores and user stores.
+- Encryption of sensitive deployment-level configuration data in configuration files.
+
+From WSO2 IS 5.11.0 onwards, symmetric encryption is used to encrypt the internal sensitive runtime data above. The DEK used to encrypt these data is configured in the `deployment.toml` file and it is protected by a KEK. The secure vault is utilized as of now to protect this DEK. Here, only the rotation of the Data Encryption Key configured in the `deployment.toml` file is considered.
+
+## DEK rotation frequency
+
+In the case of a security compliance requirement, we can see that symmetric DEK rotation can be done in 2 years or less based on the volume of data present.
+
+In a security breach scenario, we must rotate the DEK immediately and re-encrypt all the data to the new DEK.
+
+## Key Rotation Approach
+
+WSO2 IS has introduced an external tool that re-encrypts internal data after rotation of the configured symmetric data encryption key. Here, the re-encryption of the identity and registry databases and some configuration files is considered. Apart from that, the tool syncs end-user data that gets generated in the live system to the new setup.
+
+The external Java client that performs the above tasks can be created by following the steps [here](#how-to-create-the-key-rotation-tool).
+
+## Tables that support re-encryption
+
+At the moment, the tables given below are supported for re-encryption.
+
+| **Table** | **Fields** |
+|-----------|---------------|
+| IDN_IDENTITY_USER_DATA | TOTP secretKey and verifiedSecretKey claims |
+| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth2 authorization codes |
+| IDN_OAUTH2_ACCESS_TOKEN | OAuth2 access and refresh tokens |
+| IDN_OAUTH_CONSUMER_APPS | Consumer secrets
+| WF_BPS_PROFILE | BPS profile password |
+| WF_REQUEST | WF request credentials |
+| REG_PROPERTY | Keystore passwords, Keystore privatekeyPass, and Entitlement subscriberPasswords |
+
+## Configuration files that support re-encryption
+
+At the moment, the configuration files given below are supported for re-encryption.
+
+| **Configuration file** | **Path** | **Property** |
+|---------------------------|-----------|--------------|
+| Event publishers | `/repository/deployment/server/eventpublishers` files | Password |
+| Super tenant secondary user stores | `/repository/deployment/server/userstores/` files | Password |
+| Tenant secondary userstores | `/repository/tenants//userstores/` files | Password |
+
+## Tables that support syncing
+
+At the moment, the tables given below can be synced during key rotation from the old setup to the new setup. Any other data will not be persisted in the new setup.
+
+| **Table** | **Purpose** | **Recommendation** |
+|-----------|---------------|-----------------------|
+| IDN_IDENTITY_USER_DATA | Identity claims when the identity data store is enabled | Usually recommended to sync if identity management features are enabled in the system |
+| IDN_OAUTH2_ACCESS_TOKEN | OAuth 2.0 tokens | Need to sync if the tokens created during the key rotation period need to be valid after key rotation |
+| IDN_OAUTH2_ACCESS_TOKEN_SCOPE | OAuth 2.0 scopes | If the IDN_OAUTH2_ACCESS_TOKEN is synced, this table also needs to be synced |
+| IDN_OAUTH2_AUTHORIZATION_CODE | OAuth 2.0 authorization codes | Need to sync if the authorization codes created during the key rotation period need to be valid after key rotation |
+
+## How To Create The Key Rotation Tool
+
+!!! note
+ In this section, `` is the directory where the current Identity Server resides, and `` is the directory where the copy of the current Identity Server resides. `` refers to the location [here](https://github.com/wso2/identity-tools/components/org.wso2.carbon.identity.keyrotation){:target="_blank"} and the `` refers to the location of the external tool.
+
+1. Clone the repository, [identity-tools](https://github.com/wso2/identity-tools){:target="_blank"}.
+
+2. Build it using maven by running the command `mvn clean install`.
+
+3. Go to the `/target` folder and copy the `keyrotation-tool--SNAPSHOT.jar` file and the `/target/lib` folder to ``. Get the `properties.yaml` file, `keyrotation.sh` file, and the `triggers` folder from `/src/main/resources` and copy them to the same `` location.
+
+## Performing blue-green key rotation
+
+1. Block all privileged user flows and allow only end-user flows.
+
+ !!! note
+ For the privileged user flows, block all admin services from the load balancer and the management console as well. For end user flows, the above [tables]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation/#tables-that-support-re-encryption) will be synced to the ``, so only these end user data flows should be allowed to generate in ``.
+
+2. Execute the `old.sql` script in the `` identity database to create temp tables and triggers. The triggers can be found inside the `/triggers` folder.
+
+3. Create a copy of the ``(This copied directory will be referred to as the `NEW_IS_HOME`) and dump `` identity and registry databases and create the new databases.
+
+4. Drop the temp tables and triggers in the `` identity database using the `new.sql` script. The triggers can be found inside the `/triggers` folder.
+
+5. Open the `properties.yaml` file in `` and edit the configurations accordingly.
+
+ - oldSecretKey - The symmetric encryption key used in the ``.
+
+ !!! note
+ If the key is encrypted using cipher tool, decrypt it back as shown [here](https://shagihan.medium.com/decrypt-encrypted-text-with-the-wso2-cipher-tool-15b67624620a){:target="_blank"}.
+
+ - newSecretKey - The new symmetric encryption key.
+
+ !!! tip
+ Generate using a tool like openssl using the command, `openssl rand -hex 16`.
+
+ - newISHome - The absolute path of the ``.
+ - oldIdnDBUrl - `` identity database URL.
+ - oldIdnUsername - `` identity database username.
+ - oldIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
+ - newIdnDBUrl - `` identity database URL.
+ - newIdnUsername - `` identity database username.
+ - newIdnPassword - `` identity database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
+ - newRegDBUrl - `` registry database URL.
+ - newRegUsername - `` registry database username.
+ - newRegPassword - `` registry database password (Encoded in [base64](https://www.base64encode.org/){:target="_blank"}).
+ - enableDBMigrator - Enable/disable re-encryption for the identity and registry databases.
+
+ !!! note
+ Keep this always **true** to avoid unnecessary issues.
+
+ - enableConfigMigrator - Enable/disable re-encryption for the configuration files.
+
+ !!! note
+ Keep this always **true** to avoid unnecessary issues.
+
+ - enableSyncMigrator - Enable/disable syncing mechanism.
+
+ !!! note
+ You only need to set this to **true**, if you have opted in for blue-green key rotation with zero downtime for the end user flows.
+
+ - chunkSize - Size of the record chunks being retrieved from the database tables for syncing.
+
+ ??? tip "Sample configuration written for the properties.yaml file"
+
+ ```
+ oldSecretKey: AFA27B44D43B02A9FEA41D13CEDC2E40
+ newSecretKey: 1fc0bc7a3805b42afa5f5af07a595f56
+ newISHome: /home/IS/wso2is-5.12.0
+ oldIdnDBUrl: jdbc:mysql://localhost:3306/regdb?useSSL=false
+ oldIdnUsername: root
+ oldIdnPassword: cm9vdA==
+ newIdnDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false
+ newIdnUsername: root
+ newIdnPassword: cm9vdA==
+ newRegDBUrl: jdbc:mysql://localhost:3306/regdb1?useSSL=false
+ newRegUsername: root
+ newRegPassword: cm9vdA==
+ enableDBMigrator: true
+ enableConfigMigrator: true
+ enableSyncMigrator: true
+ chunkSize: 2
+ ```
+
+ ??? tip "Sample configurations written for DB type URL"
+ **H2 DB**
+ ```
+ jdbc:h2:~/Desktop/IS/copy/wso2is-5.11.0-beta5-SNAPSHOT/repository/database/WSO2IDENTITY_DB
+ ```
+ **MySQL**
+ ```
+ jdbc:mysql://localhost:3306/idndb?useSSL=false
+ ```
+ **DB2**
+ ```
+ jdbc:db2://localhost:50000/idndb
+ ```
+ **PostgreSQL**
+ ```
+ jdbc:postgresql://localhost:5432/idndb
+ ```
+ **MSSQL**
+ ```
+ jdbc:sqlserver://localhost:1433;databaseName=idndb
+ ```
+ **Oracle DB**
+ ```
+ jdbc:oracle:thin:@localhost:1521/ORCLCDB.LOCALDOMAIN
+ ```
+
+6. Run the tool using the `./keyrotation.sh keyrotation-tool--SNAPSHOT.jar` command from ``.
+
+7. Edit the `` `deployment.toml` file having the new configured databases and the new key.
+
+8. Start `` once the re-encryption for the existing DB and config file is done.
+
+9. When no new entries are being synced in the logs, route traffic to `` and enable all load balancer API endpoints(privileged and end-user flows).
+
+!!! note "Important"
+ Do not stop the tool at once, let it sync any remaining data in the temp tables after routing the traffic.
+
+## Verifying the key rotation
+
+- Check the log files to verify if re-encryption happened successfully for the 7 identity and registry database tables. Check the logs given below for the successful/failed re-encryption counts of OAuth2 access and refresh tokens.
+
+ ??? tip "DB log sample"
+ ```
+ Successfully updated OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 897
+ Failed OAuth2 access and refresh tokens data records in IDN_OAUTH2_ACCESS_TOKEN: 0
+ ```
+
+ !!! note
+ If the key rotation task is successful, the failed logs count should be `0` for all the tables.
+
+- Check the log files to verify if re-encryption happened successfully for the 3 configuration files. Check the logs given below for the successful/failed re-encryption counts of event publisher configuration files.
+
+ ??? tip "Config file log sample"
+ ```
+ Updated event publisher configuration files: 8
+ Failed event publisher configuration files: 0
+ ```
+
+ !!! note
+ If the key rotation task is successful, the failed logs count should be `0` for all the configuration files.
+
+- Check the log files to verify if the transformation of the synced data happened successfully for the 4 tables. Check the logs given below for the successful/failed transformation counts of `IDN_IDENTITY_USER_DATA` table.
+
+ ??? tip "Synced log sample"
+ ```
+ Successfully transformed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 2
+ Transformation failed totp data records in IDN_IDENTITY_USER_DATA_TEMP: 0
+ ```
+
+ !!! note
+ If the synced task is successful, the failed logs count should be `0` for all the synced tables.
+
+- Check for any errors in the log files and carefully analyze the logs if the error can be ignored and other steps can be proceeded with. Otherwise, check what has caused the error.
+
+## Recovering from any failure
+
+If the key rotation task stops midway, follow the blue green key rotation user guide steps again.
+
+If there are errors logged in the log files, carefully go through the errors and find what has caused the error.
diff --git a/en/includes/deploy/security/symmetric-encryption/index.md b/en/includes/deploy/security/symmetric-encryption/index.md
new file mode 100644
index 0000000000..f21c082bc4
--- /dev/null
+++ b/en/includes/deploy/security/symmetric-encryption/index.md
@@ -0,0 +1,105 @@
+# Symmetric Encryption
+
+Symmetric encryption uses a single key to encrypt and decrypt information. {{product_name}} uses symmetric encryption by default.
+
+!!! note
+ If required, you may switch to [asymmetric key encryption]({{base_path}}/deploy/security/asymmetric-encryption/).
+
+## Why symmetric key encryption?
+
+From {{product_name}} version 7.0.0 onwards, symmetric key encryption is used as the default encryption mechanism due to the following reasons:
+
+- **Ability to easily change key stores** - In earlier versions, internal data was encrypted using asymmetric key encryption. This means that whenever the certificates expire, or when the keystore is changed, all encrypted data should be migrated. With the shift to symmetric encryption, this overhead is now removed. The secret key involved in symmetric key encryption is encrypted using asymmetric key encryption. Therefore, the secret key needs to be re-encrypted only when the keystore changes.
+
+- **Industry-wide usage** - Symmetric key encryption is used as an accepted industry-wide mechanism for encrypting internal sensitive data. This includes both on-premise and cloud platforms.
+
+- **Post-Quantum Security** - Quantum computers have the potential to break widely-used asymmetric encryption algorithms such as RSA and ECC by efficiently solving the underlying mathematical problems. Symmetric key encryption, on the other hand, is more resistant to quantum attacks.
+
+!!! info
+ For more information on symmetric key encryption properties, see [Configure Symmetric Key Encryption]({{base_path}}/deploy/security/symmetric-encryption/use-symmetric-encryption).
+
+## How is it used?
+
+{{product_name}} uses the `AES/GCM/NoPadding` algorithm for symmetric key encryption. GCM is a stream cipher and therefore, enables simultaneous encryption of multiple blocks, resulting in faster data encryption.
+
+{% if is_version == "7.0.0" %}
+
+The supported key size is AES-128.
+
+{% else %}
+
+The supported key sizes are AES-128, AES-192, and AES-256.
+
+{% endif %}
+
+{{product_name}} uses [symmetric key encryption]({{base_path}}/deploy/security/symmetric-encryption) to encrypt the following data.
+
+- Event publisher passwords.
+- Secondary user store properties.
+- `secretKey` and `verifiedSecretKey` claims of TOTP authentication.
+- OAuth 2.0 authorization codes, access tokens, refresh tokens, and consumer secrets (when encryption is enabled).
+
+ !!! note
+
+ To enable encryption of OAuth 2.0 authorization codes, access tokens, refresh tokens, and consumer secrets, add the following configuration to the `deployment.toml` found in the `/repository/conf/` directory.
+
+ ```toml
+ [oauth.extensions]
+ token_persistence_processor = "org.wso2.carbon.identity.oauth.tokenprocessor.EncryptionDecryptionPersistenceProcessor"
+ ```
+
+- Secondary keystore passwords and private-key passwords
+- BPS profile passwords
+- Workflow request credentials
+
+For other types of encryption, [asymmetric encryption]({{base_path}}/deploy/security/asymmetric-encryption) is used by default.
+
+## Generate a secret key
+
+For enhanced security, it is recommended to generate your own secret key for symmetric key encryption in {{product_name}}.
+
+!!! warning
+ All configuration changes should be applied before starting {{product_name}} for the first time. Otherwise, a [key rotation]({{base_path}}/deploy/security/symmetric-encryption/blue-green-data-encryption-keyrotation) will be required.
+
+To do so,
+
+{% if is_version == "7.0.0" %}
+
+1. Generate a unique 128-bit secret key. If you use OpenSSL, the command will be as follows:
+
+ ```bash
+ openssl rand -hex 16
+ ```
+
+2. Add your generated key to the `deployment.toml` found in the `/repository/conf/` directory as follows:
+
+ ```toml
+ [encryption]
+ key = "9a131db7d3fce3adb0850b486bfc6528"
+ ```
+
+ !!! note
+
+ It is advised to encrypt the symmetric encryption key with a cipher tool as mentioned [here]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool).
+{% else %}
+
+1. Generate a unique 256-bit secret key. If you use OpenSSL, the command will be as follows:
+
+ ```bash
+ openssl rand -hex 32
+ ```
+
+2. Add your generated key to the `deployment.toml` found in the `/repository/conf/` directory as follows:
+
+ ```toml
+ [encryption]
+ key = "d13e3b2ea4c42eb4a23fd110facb72a596ecd84ecd5297a13065f1877393eccf"
+ ```
+
+{% endif %}
+
+If a custom encryption key is not provided, the value of `encryption.key` in this configuration file will be used as the default key.
+
+!!! note "Important"
+
+ It is highly recommended to encrypt the secret key using the [cipher tool]({{base_path}}/deploy/security/encrypt-passwords-with-cipher-tool/).
\ No newline at end of file
diff --git a/en/includes/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md b/en/includes/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md
index f62dd00ee0..8839230d79 100644
--- a/en/includes/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md
+++ b/en/includes/guides/authentication/conditional-auth/on-demand-silent-password-migration-template.md
@@ -1,10 +1,9 @@
# On-demand silent password migration
-This adaptive authentication script is specifically designed for on-demand silent password migration. A migrated user's password can be seamlessly migrated to Asgardeo using this method without forcing the user to reset the password.
+This adaptive authentication script is specifically designed for on-demand silent password migration. A migrated user's password can be seamlessly migrated to {{ product_name }} using this method without forcing the user to reset the password.
!!! note
- Learn how to set up [on-demand silent password migration]({{base_path}}/guides/users/migrate-users-to-asgardeo/migrate-passwords/).
-
+ Learn how to set up [on-demand silent password migration]({{base_path}}/guides/users/migrate-users/migrate-passwords/).
## Conditional template
Shown below is the conditional authentication template for on-demand silent password migration.
@@ -13,6 +12,8 @@ Shown below is the conditional authentication template for on-demand silent pass
Learn more about the conditional authentication functions and objects in its [API reference]({{base_path}}/references/conditional-auth/api-reference/).
+{% if product_name == "Asgardeo" %}
+
```js
var user = null;
var userId = "";
@@ -327,9 +328,316 @@ Replace the following parameters of the script with values relevant to your setu
+{% else %}
+
+```js
+var user = null;
+var userId = "";
+var username = "";
+var password = "";
+var contextId = "";
+
+var requestAuthConfig = {
+ type: "clientcredential",
+ properties: {
+ consumerKey: "",
+ consumerSecret: "",
+ tokenEndpoint: ""
+ }
+}
+
+var requestHeaders = {
+ "Content-Type": "application/json",
+ "Accept": "application/json",
+}
+
+var onLoginRequest = function(context) {
+ executeStep(1, {
+ onSuccess: function(context) {
+ Log.info("Login successful. Authenticated the user locally!");
+ },
+ onFail: function(context) {
+ resolveAndInitUser(context);
+
+ // If the user is found, proceed with the migration.
+ if (user !== null) {
+ userId = user.uniqueId;
+
+ // Check whether the user is already migrated.
+ if (user.localClaims["http://wso2.org/claims/is_migrated"] === "true") {
+ Log.info("Password is already migrated for the user: " + userId + ".");
+ sendError(null, {
+ 'status': 'Login failed!',
+ 'statusMsg': 'Please check your username and password and try again.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ } else {
+ Log.info("Password is not yet migrated for the user: " + userId + ". Starting the external authentication.");
+
+ // Start the external authentication.
+ authenticateExternally();
+ }
+ } else {
+ sendError(null, {
+ 'status': 'Login failed!',
+ 'statusMsg': 'Please check your username and password and try again.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ }
+ });
+};
+
+
+/**
+ * This function will resolve the user using the login identifier and initialize the login variables.
+ */
+var resolveAndInitUser = function(context) {
+
+ // Retrieve login identifier and password provided by the user.
+ var loginIdentifier = context.request.params.username[0];
+ password = context.request.params.password[0];
+
+ Log.info("User login initiated for the user: " + loginIdentifier);
+
+ // If your organization has enabled alternative login identifiers, the username has to be resolved using the login identifier.
+ // If not, uncomment the immediate next line and comment out rest of the section.
+ // username = loginIdentifier;
+ Log.info("Resolving username using the login identifier: " + loginIdentifier);
+ username = resolveMultiAttributeLoginIdentifier(loginIdentifier, context.tenantDomain);
+ Log.info("Username resolved using the login identifier. Resolved username: " + username);
+ // End of username resolving section.
+
+ // Retrieve unique user object for the username.
+ var claimMap = {};
+ claimMap["http://wso2.org/claims/username"] = "PRIMARY/" + username;
+ user = getUniqueUserWithClaimValues(claimMap, context);
+};
+
+
+/**
+ * This function will authenticate the user with the external service.
+ */
+var authenticateExternally = function() {
+
+ var requestPayload = {
+ id: userId,
+ username: username,
+ password: password
+ };
+
+ Log.info("Invoking the external authentication endpoint for the user: " + userId + ".");
+
+ // Invoke the start authentication API.
+ httpPost("", requestPayload, requestHeaders, requestAuthConfig, {
+ onSuccess: function(context, data) {
+ if (data !== null && data.message !== null) {
+ if (data.message === "Received") {
+ // Set the context ID to be used in subsequent requests.
+ contextId = data.contextId;
+
+ Log.info("Started external authentication for the user: " + userId + " with context ID: " + contextId + ". Redirecting to the waiting page.");
+
+ // Redirect to the waiting page to wait until the external authentication is completed.
+ prompt("internalWait", {
+ "waitingType": "POLLING",
+ "waitingConfigs": {
+ "timeout": "10",
+ "pollingEndpoint": "",
+ "requestMethod": "GET",
+ "requestData": "contextId=" + contextId,
+ "pollingInterval": "2"
+ }
+ }, {
+ onSuccess: function(context) {
+ Log.info("Successfully redirected back from the waiting page.");
+
+ // Check authentication status, update password and re-authenticate the user.
+ updatePasswordAndReAuthenticate();
+ },
+ onFail: function(context, data) {
+ Log.info("Error occurred while redirecting. Please retry!");
+ }
+ });
+ } else {
+ Log.info("External authentication failed for the user: " + userId + ". Message: " + data.message + ".");
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ } else {
+ Log.info("External authentication failed for the user: " + userId + ".");
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ },
+ onFail: function(context, data) {
+ Log.info("Error occurred while invoking the external API to start authentication.");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ },
+ onTimeout: function(context, data) {
+ Log.info("Connection timed out while invoking the external API to start authentication.");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ });
+};
+
+
+/**
+ * This function will check for the authentication status, update the password and re-authenticate.
+ */
+var updatePasswordAndReAuthenticate = function() {
+
+ var requestPayload = {
+ contextId: contextId,
+ username: username
+ };
+
+ Log.info("Invoking the external API to check auth status for the user: " + userId + " with context ID: " + contextId + ".");
+
+ // Invoke the external authentication API.
+ httpPost("", requestPayload, requestHeaders, requestAuthConfig, {
+ onSuccess: function(context, data) {
+ if (data.status !== null && data.status === "SUCCESS") {
+ Log.info("External authentication is successful for the user: " + userId + ". Proceeding with password update.");
+
+ // Update the user password.
+ updateUserPassword(user, password, {
+ onSuccess: function(context) {
+ Log.info("Password updated successfully for the user: " + userId + ".");
+
+ // Set the password migration flag to true.
+ user.localClaims["http://wso2.org/claims/is_migrated"] = "true";
+
+ reAuthenticate();
+ },
+ onFail: function(context) {
+ Log.info("Failed to update password of the user: " + userId + ".");
+ }
+ });
+ } else if (data.status !== null && data.status === "FAIL") {
+ var errorMessage = "";
+ if (data.message !== null) {
+ errorMessage = data.message;
+ }
+
+ Log.info("External authentication failed for the user: " + userId + ". Message: " + errorMessage + ".");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'External authentication failed with the error: ' + errorMessage + '. Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ } else {
+ var errorMessage = "";
+ if (data.message !== null) {
+ errorMessage = data.message;
+ }
+
+ Log.info("Something went wrong during the external authentication for the user: " + userId + ". Message: " + errorMessage + ".");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ },
+ onFail: function(context, data) {
+ Log.info("Error occurred while invoking the external API to check auth status.");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ },
+ onTimeout: function(context, data) {
+ Log.info("Connection timed out while invoking the external API to check auth status.");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ });
+};
+
+
+/**
+ * This function will re-authenticate the user with the new password.
+ */
+var reAuthenticate = function() {
+
+ // Re-authenticate without prompting user input.
+ Log.info("Re-authenticating the user: " + userId + " with the new password.");
+
+ executeStep(1, {
+ authenticatorParams: {
+ common: {
+ 'username': username,
+ 'password': password
+ }
+ },
+ }, {
+ onSuccess: function(context) {
+ Log.info("Re-authentication successful for the user: " + userId + ".");
+ },
+ onFail: function() {
+ Log.info("Re-authentication failed for the user: " + userId + ".");
+
+ sendError(null, {
+ 'status': 'Authentication failed',
+ 'statusMsg': 'Please contact your administrator.',
+ 'i18nkey': 'auth.fail.error'
+ });
+ }
+ });
+};
+```
+
+Replace the following parameters of the script with values relevant to your setup:
+
+
+
+
start_authentication_endpoint
+
URL of the start authentication endpoint deployed in an external service
+
+
+
polling_endpoint
+
URL of the polling endpoint deployed in an external service
+
+
+
authentication_status_endpoint
+
URL of the authentication status endpoint deployed in an external service
+
+
+
requestAuthConfig
+
An object containing necessary authentication metadata to invoke the APIs. Refer Conditional authentication - API reference for more information.
+
+
+ {% if "navigation.footer" in features %}
+ {% if page.previous_page or page.next_page %}
+ {% if page.meta and page.meta.hide %}
+ {% set hidden = "hidden" if "footer" in page.meta.hide %}
+ {% endif %}
+
+ {% endif %}
+ {% endif %}
+