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 nameDescription
Email AddressProvide 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 AddressThe 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. +
RoleThe 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/).
RoleUsers 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 nameis_migrated
Attribute Display NamePassword 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 ? ( +
{ + "use server" + await signIn("asgardeo") + }} + > + +
+ ) : ( + <> +

You are now signed in!

+ +
{ + "use server" + await signOut() + }} + > + +
+ + ) + } +
+ ); +} +``` + +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}

+
{ + "use server" + await signOut() + }} + > + +
+ +... + +``` + 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 ? - <> -

Welocme {state.username}

- - - : - } + { + state.isAuthenticated ? + <> +

Welcome {state.username}

+ + + : + } ) }; 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AdministratorThis role provides all administrative permissions in the organization. An administrator is a privileged user who has overall access to the organization.
AuditorThis 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 - ApplicationsThis role provides permissions for registering and managing applications, ideal for privileged users who can integrate applications with Asgardeo.
Viewer - ApplicationsThis 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 - UsersThis role provides permissions for managing users and groups within the organization.
Viewer - UsersThis role provides permissions required for viewing users and groups.
Editor - ConnectionsThis 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. false 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 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 ? ( +
{ + "use server" + await signIn("asgardeo") + }} + > + +
+ ) : ( + <> +

You are now signed in!

+ +
{ + "use server" + await signOut() + }} + > + +
+ + ) + } +
+ ); +} +``` + +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}

+
{ + "use server" + await signOut() + }} + > + +
+ + +... + +``` + + + + 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 ? - <> -

Welocme {state.username}

- - - : - } + { + state.isAuthenticated ? + <> +

Welcome {state.username}

+ + + : + } ) }; 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. false 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 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. false 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/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. - - - - - + - - + + - - + + - - - - - - + + + + + +
DomainThe 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 TenantThe 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 NameThe name of the tenant admin.First NameThe first name of the root organization admin.
Admin UsernameThe sign-in username of the tenant admin. The username always ends with the domain name (e.g., admin@abc.com).Last NameThe last name of the root organization admin.
Admin PasswordThe password used to sign in using the admin username specified.
Admin Password (Repeat)Repeat the password to confirm.UsernameThe username of the root organization admin that will be used for signing in.
Email The email address of the admin.
PasswordThe 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_endpointURL of the start authentication endpoint deployed in an external service
polling_endpointURL of the polling endpoint deployed in an external service
authentication_status_endpointURL of the authentication status endpoint deployed in an external service
requestAuthConfigAn object containing necessary authentication metadata to invoke the APIs. Refer Conditional authentication - API reference for more information.
+ +{% endif %} + ## How it works -Let's look at how the above conditional authentication scripts works. +Let's look at how the above conditional authentication script works. 1. The first authentication step (Username & Password) is initiated with the `executeStep(1, ..)` function. Based on its status, one of the following happens. @@ -357,22 +665,35 @@ Let's look at how the above conditional authentication scripts works. 4. The script calls for external authentication with the `authenticateExternally` function and it works as follows: + {% if product_name == "Asgardeo" %} - The `connectionMetadata` object holds the start authentication endpoint URL, Choreo application credentials and the Asgardeo token endpoint. - The script first calls the `callChoreo()` function along with the `connectionMetaData` and invokes the start authentication endpoint. + {% else %} + - The `requestAuthConfig` object holds the necessary authentication metadata to invoke the APIs. + - The script first calls the `httpPost()` function along with the `requestAuthConfig` and invokes the start authentication endpoint. + {% endif %} + - If the API call is successful, the `onSuccess()` callback function is called which in turn calls the `prompt()` function. + + {% if product_name == "Asgardeo" %} - The `prompt()` function continuously polls the Choreo polling endpoint and redirects the user to a waiting page until the external authentication completes. + {% else %} + - The `prompt()` function continuously polls the external polling endpoint and redirects the user to a waiting page until the external authentication completes. + {% endif %} + - Once the authentication is complete, the `onSuccess()` callback function of the `prompt()` function calls the `updatePasswordAndReAuthenticate()` function. 5. The `updatePasswordAndReAuthenticate()` function is responsible for checking the status of the authentication and taking necessary actions as explained below. - - The `connectionMetadata` object hold the authentication status endpoint URL, Choreo application credentials and the Asgardeo token endpoint + {% if product_name == "Asgardeo" %} + - The `connectionMetadata` object hold the authentication status endpoint URL, Choreo application credentials and the Asgardeo token endpoint. - The script first calls the `callChoreo()` function along with the `connectionMetaData` and invokes the authentication status endpoint. + {% else %} + - The `requestAuthConfig` object holds the necessary authentication metadata to invoke the APIs. + - The script first calls the `httpPost()` function along with the `requestAuthConfig` and invokes the authentication status endpoint. + {% endif %} + - If the API call is successful, the `onSuccess()` callback function is called and the response message is checked. If it is `SUCCESS`, the external authentication was successful. - - The script then calls the `updateUserPassword()` function to update the user password in the Asgardeo user store. + - The script then calls the `updateUserPassword()` function to update the user password in the {{ product_name }} user store. - Afterwards, the `is_migrated` attribute of the user is set to `true` and the user is re-authenticated. - The `reAuthenticate()` function that handles the re-authentication performs a silent authentication. This means that the user is not prompted to enter the credentials again. - - - - - diff --git a/en/includes/guides/authentication/configure-token-exchange.md b/en/includes/guides/authentication/configure-token-exchange.md index 2d8119c449..c1c0704563 100644 --- a/en/includes/guides/authentication/configure-token-exchange.md +++ b/en/includes/guides/authentication/configure-token-exchange.md @@ -38,10 +38,20 @@ To register a trusted token issuer: 4. Click **Next** and provide the mode of certificate configuration. - !!! note - You can either configure a JWKS endpoint or upload a certificate of the external party. This is required to validate the signature of the assertions sent by the external identity provider. - - **JWKS endpoint**: The JWKS endpoint of the trusted token issuer. + + {% if product_name == "WSO2 Identity Server" %} + + !!! note + + For JWKS endpoints, the default read timeout is 1000 milliseconds. You may change this value by adding the following parameter to the `deployment.toml` file found in the `/conf/repository` directory. + + ```toml + [oauth.jwks_endpoint] + read_timeout = + ``` + {% endif %} + - **Use PEM certificate**: Upload or paste the public certificate of the trusted token issuer. The certificate should be in PEM format. ??? note "If you have a certificate in other formats such as `.crt`, `.cer` or `.der`, expand here to see how you can convert them to PEM format using [OpenSSL](https://www.openssl.org/){:target="_blank"}" diff --git a/en/includes/guides/authentication/federated-login/index.md b/en/includes/guides/authentication/federated-login/index.md index 73b5f0dced..4e8e845013 100644 --- a/en/includes/guides/authentication/federated-login/index.md +++ b/en/includes/guides/authentication/federated-login/index.md @@ -30,6 +30,7 @@ You can register an external IdP in {{product_name}} by creating a connection. { Microsoft Microsoft + {% if product_name == "WSO2 Identity Server" %} Microsoft 365 Microsoft 365 @@ -38,7 +39,6 @@ You can register an external IdP in {{product_name}} by creating a connection. { Microsoft IWA
IWA
- {% if product_name == "WSO2 Identity Server" %} X
X
@@ -53,10 +53,12 @@ You can register an external IdP in {{product_name}} by creating a connection. { SAML SAML
+ {% if product_name == "WSO2 Identity Server" %} WS-Fed


WS-Federation
+ {% endif %} {% if product_name == "Asgardeo" %} Ethereum
diff --git a/en/includes/guides/authentication/oidc/jarm.md b/en/includes/guides/authentication/oidc/jarm.md index 9604cce1c2..db5c69e89a 100644 --- a/en/includes/guides/authentication/oidc/jarm.md +++ b/en/includes/guides/authentication/oidc/jarm.md @@ -10,10 +10,10 @@ Below is a sample authorization request sent to the authorization endpoint of th https://api.asgardeo.io/t//oauth2/authorize? prompt=login &scope=openid -&redirect_uri=https://<CLIENT_HOST>/redirects/redirect1 -&client_id=<CLIENT_ID> -&response_type=<RESPONSE_TYPE> -&response_mode=<RESPONSE_MODE> +&redirect_uri=https:///redirects/redirect1 +&client_id= +&response_type= +&response_mode= ``` The parameters used in the authorization request are defined below. diff --git a/en/includes/guides/customize/actions/pre-issue-access-token-action b/en/includes/guides/customize/actions/pre-issue-access-token-action index d2b9f721d3..8d8ff3e5d1 100644 --- a/en/includes/guides/customize/actions/pre-issue-access-token-action +++ b/en/includes/guides/customize/actions/pre-issue-access-token-action @@ -338,14 +338,13 @@ When {{product_name}} invokes your external service as part of the pre-issue acc This response plays a crucial role in determining how the access token is ultimately issued or modified. Here’s a breakdown of the expected response: -The response can have two possible states: SUCCESS and ERROR. +The response can have three possible states: SUCCESS, FAILEDand ERROR. -SUCCESS: Indicates that the request was processed successfully and includes any state changes or modifications that should be applied. +SUCCESS: Indicates that the request was processed successfully, including any state changes or modifications that need to be applied. -ERROR: Indicates a failure in processing, accompanied by an error message that should be communicated to the application. This error message should adhere to OAuth 2.0 error response definitions to ensure compliance. However, it is your responsibility to ensure this compliance when extending the flow. +FAILED: Represents a selective failure within the token flow due to validation logic or business rules enforced by your external service. A 400 (Client Error) response is returned to the application, incorporating the failure message provided by your external service. It is your responsibility to supply an OAuth 2.0-compliant failure message when extending the flow. -!!! note - Currently, ERROR responses are not communicated back to the client, but this functionality is planned for inclusion by end October 2024. +ERROR: Indicates a processing failure, typically caused by server-side issues. A 500 (Server Error) response is returned to the application. #### Response for SUCCESS state: @@ -376,9 +375,68 @@ Http Status Code: 200 !!! tip Refer the [sample responses for successful access token updates]({{base_path}}/references/actions/pre-issue-access-token-action/sample-success-responses/) to learn how to construct success responses for different scenarios. +#### Response for FAILED state: + +When the external service returns a 200 OK status code with a FAILED state, it means the service has intentionally opted to prevent access token issuance. This decision is based on specific validation logic or business rules defined by your application's requirements. + +The response body must be a JSON object containing the following properties: + +Http Status Code: 200 + + + + + + + + + + + + + + + + + + + + + + + +
PropertyDescription
actionStatus

Indicates the outcome of the request. For a failed operation, this should be set to FAILED.

failureReason

Provides the reason for failing to issue an access token. This value will be mapped to the error field in the response returned from the /oauth2/token endpoint..

failureDescription

Offers a detailed explanation of the failure. This value will be mapped to the error_description field in the /oauth2/token endpoint response.

+ +Below is an example of a failed response due to invalid scopes in the access token request. + +Response from external service: +```http +HTTP/1.1 200 OK +Content-Type: application/json + +{ + "actionStatus": "FAILED", + "failureReason": "invalid_scope", + "failureDescription": "Scope platinum_state is invalid" +} +``` + +This will result in the following error response being sent to the application that initiated the token request. + +Error response to the application: +```http +HTTP/1.1 400 +Content-Type: application/json + +{ + "error": "invalid_scope", + "error_description": "Scope platinum_state is invalid" +} +``` + #### Response for ERROR state: -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. +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. Http Status Code: 400, 401 or 500 @@ -396,8 +454,8 @@ Http Status Code: 400, 401 or 500 -error -

The error code, as specified in OAuth 2.0 error response definitions..

+errorMessage +

Describes the cause of the error..

errorDescription @@ -406,7 +464,35 @@ Http Status Code: 400, 401 or 500 -!!! note - Currently, ERROR responses are not communicated back to the client, but this functionality is planned for inclusion by end October 2024. +If the external service returns an error response (either defined or undefined) or fails to respond entirely, it will be treated as an error in executing the action. In any of these cases, the application that initiated the token request will receive a 500 Internal Server Error. + +Below is an example of an error response returned by the service implementing the pre issue access token action. + +Response from external service: +```http +HTTP/1.1 500 +Content-Type: application/json + +{ + "actionStatus": "ERROR", + "errorMessage": "Server error", + "errorDescription": "Error while processing request." +} +``` + +This will result in the following error response being sent to the application that initiated the token 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. +Error response to the application: +```http +HTTP/1.1 500 +Content-Type: application/json + +{ + "error":”server_error", + "error_description": "Internal Server Error." +} + +``` + +!!! note + Currently, the errorMessage or errorDescription from the external service’s ERROR response is not directly included in the error response sent back to the application. diff --git a/en/includes/guides/encryption/symmetric-encryption.md b/en/includes/guides/encryption/symmetric-encryption.md deleted file mode 100644 index 6d76a86b4d..0000000000 --- a/en/includes/guides/encryption/symmetric-encryption.md +++ /dev/null @@ -1,16 +0,0 @@ -# Symmetric Encryption - -In symmetric encryption, a single key is used for the encryption and decryption of information. In WSO2 Identity Server version 7.0.0, symmetric encryption is used by default. If required, you may switch to [asymmetric key encryption]({{base_path}}/deploy/security/asymmetric-encryption/). - -## Why symmetric key encryption? - -In all versions of WSO2 Identity Server prior to 5.11.0, asymmetric key encryption was used for signing purposes and for encrypting internal data. However, from 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). diff --git a/en/includes/guides/fragments/manage-app/oidc-settings/access-token.md b/en/includes/guides/fragments/manage-app/oidc-settings/access-token.md index 4604f0fcae..f67776ebae 100644 --- a/en/includes/guides/fragments/manage-app/oidc-settings/access-token.md +++ b/en/includes/guides/fragments/manage-app/oidc-settings/access-token.md @@ -2,7 +2,7 @@ #### Token type {{product_name}} supports the following token types. -- *Opaque*: Opaque tokens are plain text tokens. If a resource server wants to know information related to an opaque token, it has to call the introspection endpoint and receive information related to tokens. An example for a opaque token response is shown below. +- **Opaque**: Opaque tokens are plain text tokens. If a resource server wants to know information related to an opaque token, it has to call the introspection endpoint and receive information related to tokens. An example for a opaque token response is shown below. ```json { @@ -14,7 +14,7 @@ } ``` -- *JWT token*: JWT tokens are self-contained verifiable access tokens. If a resource server wants to know the information related to that token, it can decode the token and get the required information without any additional network calls. An example for a JWT token response is shown below. +- **JWT**: JWT tokens are self-contained verifiable access tokens. If a resource server wants to know the information related to that token, it can decode the token and get the required information without any additional network calls. An example for a JWT token response is shown below. ```json { @@ -27,6 +27,15 @@ ```
+{% if product_name == "Asgardeo" or (product_name == "WSO2 Identity Server" and is_version != "7.0.0") %} +#### Access Token Attributes + +For **JWT** access tokens, this feature enables you to specify which user attributes are included in the access token. As a result, when a user logs in to an application, only the chosen attributes are shared, providing enhanced security and flexibility. + +![Access-Token-Attributes]({{base_path}}/assets/img/guides/authorization/access-token/access-token-attributes.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} + +{% endif %} + #### Token binding type Token binding securely links authentication tokens to client devices to prevent unauthorized token theft and replay attacks. It is a vital mechanism, especially when dealing with unsecured networks, as it provides an additional layer of security against unauthorized access. diff --git a/en/includes/guides/fragments/migrate-users/configure-choreo-for-password-migration.md b/en/includes/guides/fragments/migrate-users/configure-choreo-for-password-migration.md new file mode 100644 index 0000000000..fa3dcf2f82 --- /dev/null +++ b/en/includes/guides/fragments/migrate-users/configure-choreo-for-password-migration.md @@ -0,0 +1,115 @@ +### 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. + +{% if product_name == "Asgardeo" %} + +!!! 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"}. + +{% else %} + +!!! note + You may find a sample Ballerina authentication service [here](https://github.com/wso2/samples-is/tree/master/user-migration-samples/is/external-authentication-service){target="_blank"}. + +{% endif %} + +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, + +{% if product_name == "Asgardeo" %} + +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. + +{% else %} + +1. Go to the [Choreo Console](https://console.choreo.dev/login){target="_blank"} and login to your account or create an account if you don't have one already. + +{% endif %} + +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 {{ product_name }} 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"}. diff --git a/en/includes/guides/users/attributes/manage-attributes.md b/en/includes/guides/users/attributes/manage-attributes.md index a944f0bed3..2361e685c8 100644 --- a/en/includes/guides/users/attributes/manage-attributes.md +++ b/en/includes/guides/users/attributes/manage-attributes.md @@ -1,31 +1,31 @@ # Manage attributes -An attribute is a piece of information about a particular user. It can be anything associated with the user, such as name, group, preferences, etc. +An attribute encapsulates a single, identifiable characteristic of a user. They may range from basic identifiers such as first name, last name, home address to dynamic properties like membership status. -User attributes represent information directly related to the user, such as the street address, username, email, first name, and more. +Attributes play a crucial role in managing user information within an organization and enables applications to access the required data seamlessly. Additionally, attributes are used to manage and display user information in user profiles. -You need user attributes to maintain the required user information in an organization. You can select the user information for your applications by using these attributes. Also, the user information displayed in user profiles is managed using attributes. - -See the information given below to manage attributes in your organization. +The following guides explain how you may manage attributes of an organization. ## View attributes -To view the attributes available for your organization: -1. On the {{ product_name }} Console, go to {{ attribute_path }} > **Attributes**. -2. Click **Attributes** again under the **Manage Attributes** section. +To view attributes available for your organization: + +1. On the {{ product_name }} Console, go to **User Attributes & Stores** > **Attributes**. + +2. Under **Manage Attributes**, click **Attributes**. ![Attributes]({{base_path}}/assets/img/guides/organization/attributes/local-attributes.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -You can now see the complete list of attributes along with **Attribute Display Name** and **Attribute** name. + This page displays all the attributes available in your organization. -![View attributes]({{base_path}}/assets/img/guides/organization/attributes/view-attributes.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} + ![View attributes]({{base_path}}/assets/img/guides/organization/attributes/view-attributes.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} ## Add custom attributes -To add a custom attribute: +Apart from the default attributes, you may define your own custom attributes by following the steps below: -1. On the {{ product_name }} Console, go to {{ attribute_path }} > **Attributes**. -2. Click **Attributes** to see the list of attributes. +1. On the {{ product_name }} Console, go to **User Attributes & Stores** > **Attributes**. +2. Under **Manage Attributes**, click **Attributes** to view the list of all attributes 3. Click **New Attribute** and enter values for the following properties: ![Custom attribute]({{base_path}}/assets/img/guides/organization/attributes/new-custom-attribute.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} @@ -38,11 +38,15 @@ To add a custom attribute: Protocol Mappings - Mappings are auto-generated for the protocols. You can customize them here. + Mappings for each protocol are generated automatically based on the attribute name. You may also customize them here. Attribute Display Name - The name that will be used in a user's profile. + The name of the attribute that will be displayed in users' profiles. + + + Regular expression + The value of the attribute will be validated against the regex pattern specified here. @@ -52,8 +56,8 @@ To add a custom attribute: ## Update attributes To update the properties of a user attribute: -1. On the {{ product_name }} Console, go to {{ attribute_path }} > **Attributes**. -2. Click **Attributes** to see the list of attributes. +1. On the {{ product_name }} Console, go to **User Attributes & Stores** > **Attributes**. +2. Under **Manage Attributes**, click **Attributes** to view the list of all attributes. 3. Click **Edit** for the attribute you want to update. ![Edit attributes]({{base_path}}/assets/img/guides/organization/attributes/edit-attributes-general.png){: width="600" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} @@ -88,14 +92,18 @@ To update the properties of a user attribute: -5. Go to the **Mapped Attributes** tab and enter the attribute from each user store that you need to map. +5. Go to the **Attribute Mappings** tab and enter the attribute from each user store that you need to map. ![Edit attribute mappings]({{base_path}}/assets/img/guides/organization/attributes/edit-attribute-mappings.png){: width="500" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} -6. Go to the **Additional Properties** tab and add additional properties that can be used when writing an extension. +{% if product_name == "WSO2 Identity Server" %} + +6. Optionally, you may use the **Additional Properties** tab to add additional properties that can be used when writing an extension. ![Edit additional properties]({{base_path}}/assets/img/guides/organization/attributes/edit-attributes-additional-properties.png){: width="500" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} +{% endif %} + ## Delete attributes !!! warning "Before you proceed" @@ -117,3 +125,39 @@ To delete an attribute: !!! note Only custom attributes can be deleted. + + +## Assign multiple email addresses and mobile numbers to a user + +{{ product_name }} allows users to associate multiple email addresses and mobile numbers with their profiles. For users with multiple values, they may also select a primary email address and a primary mobile number. + +The following attributes are used for this purpose: + +- Email Addresses +- Verified Email Addresses +- Mobile Numbers +- Verified Mobile Numbers + +### Enable/Disable these attributes for users + +Unless you have configured {{ 'secondary' if product_name == 'WSO2 Identity Server' else 'remote' }} user stores, the email address/mobile number-related attributes are already enabled to new and existing organizations. To manually enable/disable these attributes, follow the steps below: + +1. On the {{ product_name }} Console, navigate to **User Attributes and Stores** > **Attributes**. +2. Under **Manage Attributes**, click **Attributes** to view the list of all attributes. +3. Click **Edit** next to the corresponding attribute. +4. Enable/Disable the **Display this attribute on the user's profile** checkbox. +5. Click **Update** to save the changes. + +### Exclude these attributes from a user store + +For non-JDBC {{ 'secondary' if product_name == 'WSO2 Identity Server' else 'remote' }} user stores, you must ensure proper mapping of these attributes in the user store. If mapping is not feasible, you can disable support for these attributes in that user store by following the steps below. + + 1. On the {{ product_name }} Console, navigate to **User Attributes and Stores** > **Attributes**. + 2. Under **Manage Attributes**, click **Attributes** to view the list of all attributes. + 3. Click **Edit** for the attribute you wish to modify. + 4. Go to the **Attribute Mappings** tab. + 4. Find the corresponding user store and uncheck the **Enable for this user store** checkbox. + 5. Click **Update** to save the changes + + ![Enable for user store]({{base_path}}/assets/img/guides/organization/attributes/enable-for-user-store.png){: width="500" style="display: block; margin: 0; border: 0.3px solid lightgrey;"} + diff --git a/en/includes/guides/users/migrate-users/index.md b/en/includes/guides/users/migrate-users/index.md new file mode 100644 index 0000000000..fbbd118007 --- /dev/null +++ b/en/includes/guides/users/migrate-users/index.md @@ -0,0 +1,11 @@ +# Migrate users to {{ product_name }} + +Organization owners sometimes require to migrate users from an existing Identity Provider (IdP) to {{ product_name }} for the following reasons: + +- Combine users of multiple systems to a single IdP for proper user management. +- Reorganize, restructure, and simplify user data storage. +- Combine user data storages to ease centralized user management and to facilitate company acquisitions and mergers. +- Move or separate identity data due to geopolitical, data protection, compliance, and regulatory requirements. +- Improve identity management by providing increased security, scalability, and reduced maintenance costs. + +{{product_name}} provides convenience means to migrate users from an external IdP. Learn how to [migrate user accounts]({{base_path}}/guides/users/migrate-users/migrate-users/) and [migrate user passwords]({{base_path}}/guides/users/migrate-users/migrate-passwords/). diff --git a/en/includes/guides/users/migrate-users/migrate-passwords.md b/en/includes/guides/users/migrate-users/migrate-passwords.md new file mode 100644 index 0000000000..a432084801 --- /dev/null +++ b/en/includes/guides/users/migrate-users/migrate-passwords.md @@ -0,0 +1,236 @@ +# Migrate passwords to {{ product_name }} + +You may use one of the following two ways to migrate user passwords to {{ product_name }}. + +## 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 {{ product_name }} 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 {{ product_name }}. + +{% if product_name == "Asgardeo" %} + +If you wish to migrate user passwords using this method, inform the Asgardeo team along with your request to [migrate users]({{base_path}}/guides/users/migrate-users/migrate-users/). + +{% endif %} + +## Migrate with on-demand silent migration + +Compared to the 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 {{ product_name }} login screen. + +3. The user enters the usual credentials for the legacy IdP. + +4. If user's password is already migrated, the user is logged in. If not, {{ product_name }} makes an authentication request to the legacy IdP with the user provided credentials. + +5. {{ product_name }} redirects the user to a waiting page until the legacy IdP completes the authentication. + +6. Once the process is complete, the user is redirected back to the application and {{ product_name }} 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 {{ product_name }}. + +!!! note + + If you wish to migrate users with this method, it is crucial to note the following: + + - The legacy IdP should run 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. + - Users who were not migrated must contact the administrators to initiate a password reset process, facilitating a smooth and complete transition. + +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 migration]({{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 {{ product_name }} has not already migrated the user account, + + - User's login fails. + - {{ product_name }} attempts to find a user corresponding to the provided login identifier. + - If found, {{ product_name }} 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, + + - {{ product_name }} 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. + +{% if product_name == "Asgardeo" %} + + !!! 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. + +{% else %} + + !!! note + + This API is part of an authentication service that should be deployed in an external system such as [Choreo](https://wso2.com/choreo/){target="_blank"}, WSO2's integration platform. The service is designed to facilitate authentication against the legacy IdP. + +{% endif %} + +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. {{ product_name }} 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, {{ product_name }} will + + - migrate the user's password to {{ product_name }}. + - 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 {{ product_name }}]({{base_path}}/guides/users/migrate-users/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. + +{% if product_name == "Asgardeo" %} + +- 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. + +{% endif %} + +{% if product_name == "Asgardeo" %} + +{% include "../../../guides/fragments/migrate-users/configure-choreo-for-password-migration.md" %} + +{% else %} + +### Step 1: Develop and deploy the external authentication service + +On-demand silent password migration requires an external authentication service that communicates with the legacy IdP to authenticate users. This service can be developed using any programming language and can be deployed in an external system such as [Choreo](https://wso2.com/choreo/){target="_blank"}, WSO2's integration platform. + +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 external authentication service. However, ensure no sensitive information or Personally Identifiable Information (PII) are included in the logs. + +!!! note + Learn how to [configure the external authentication service in Choreo]({{base_path}}/references/tutorials/configure-choreo-for-password-migration/). + +{% endif %} + +{% if product_name == "Asgardeo" %} + +### Step 4: Configure an attribute in {{ product_name }} to hold the migration status + +{% else %} + +### Step 2: Configure an attribute in {{ product_name }} to hold the migration status + +{% endif %} + +{{ product_name }} should have means to check whether a user's password is migrated or not. This can be achieved by creating a user attribute in {{ product_name }} to hold the migration status. To do so, + +1. On the {{ product_name }} Console, go to **User Attributes & Stores** > **Attributes** and click on **Attributes**. + +2. Click **New Attribute** and enter the following details: + + + + + + + + + + +
Attribute nameis_migrated
Attribute Display NamePassword migration status
+ +3. Click **Finish** to create the attribute. + +{% if product_name == "Asgardeo" %} + +### Step 5: Configure the login flow of the {{ product_name }} application + +{% else %} + +### Step 3: Configure the login flow of the {{ product_name }} application + +{% endif %} + +You are now ready to configure your application for on-demand silent password migration. To do so, + +1. On the {{ product_name }} Console, click **Applications**. + +2. Select the application and go to its **Login Flow** tab. + +{% if product_name == "Asgardeo" %} + +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/). + +{% else %} + + 1. Go to **Predefined Flows** > **Basic Login Flows** and select **Username & Password** under **Add Basic Login**. + + 2. 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/). + +{% endif %} + +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 {{ product_name }} 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. {{ product_name }} will migrate the password and log the user in once the external authentication is successful. diff --git a/en/includes/guides/users/migrate-users/migrate-users.md b/en/includes/guides/users/migrate-users/migrate-users.md new file mode 100644 index 0000000000..a5a0cac59f --- /dev/null +++ b/en/includes/guides/users/migrate-users/migrate-users.md @@ -0,0 +1,90 @@ +# Migrate user accounts to {{ product_name }} + +This guide explains how you may prepare and execute a user migration from another Identity Provider (IdP) to {{ product_name }}. + +## Prepare for migration + +Before migrating users to {{ product_name }}, 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. When planning for a migration, be sure to go through with the following steps. + +- **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** + + {{ product_name }} 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 {{ product_name }}. 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 + +{% if product_name == "Asgardeo" %} + +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/migrate-passwords/). + +!!! note + Make sure to request using the email address registered with an owner account or an administrator account. + +{% else %} + +{{ product_name }} supports bulk importing multiple users, which can be used for the user migration. See how to [onboard multiple users]({{base_path}}/guides/users/manage-users/#onboard-multiple-users/). However this will ask users to set their own passwords for the new system. + +If you need to migrate existing user passwords as well, {{ product_name }} supports [on-demand silent password migration]({{base_path}}/guides/users/migrate-users/migrate-passwords/#migrate-with-on-demand-silent-migration/) which allows users to log in with their existing passwords and silently migrate them to the new system. For this you can use the [SCIM 2.0 Bulk API]({{base_path}}/apis/scim2/scim2-bulk-rest-api/). Below is a sample request to import the users. + +```java +curl -i -X POST --location 'https://localhost:9443/scim2/Bulk' \ +--header 'Authorization: Basic YWRtaW46YWRtaW4=' \ +--header 'Content-Type: application/json' \ +--data-raw '{ +"failOnErrors": 1, +"schemas": [ + "urn:ietf:params:scim:api:messages:2.0:BulkRequest" +], +"Operations": [ + { + "method": "POST", + "path": "/Users", + "bulkId": "ytrewq", + "data": { + "schemas": [ + "urn:ietf:params:scim:schemas:core:2.0:User", + "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" + ], + "userName": "jesse", + "password": "random", + "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { + "askPassword" : "false" + } + } + } +] +}' +``` + +!!! note + + This method requires setting a random password for the user accounts initially. We recommend setting a strong random password for each user account that will get updated during the silent password migration process. + +{% endif %} diff --git a/en/theme/material/assets/css/complete-guide.css b/en/theme/material/assets/css/complete-guide.css new file mode 100644 index 0000000000..53a2b63d9d --- /dev/null +++ b/en/theme/material/assets/css/complete-guide.css @@ -0,0 +1,73 @@ +/** + * Copyright (c) 2024, WSO2 LLC. (https://www.wso2.com). + * + * WSO2 LLC. licenses this file to you under the Apache License, + * Version 2.0 (the "License"); you may not use this file except + * in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +.md-sidebar--secondary { + display: none !important; +} + +.md-nav__item { + position: relative; + padding-right: .6rem; + display: flex; + flex-direction: row; + vertical-align: top; + margin-bottom: 10px; +} + +.md-nav__item > .guide-page-number { + display: inline-block; + margin-top: 1px; + margin-right: 10px; + background: var(--md-default-fg-color--light); + color: var(--md-default-bg-color); + font-size: 12px; + border-radius: 50%; + height: 22px; + width: 22px; + flex: 0 0 22px; + line-height: 22px; + text-align: center; +} + +.md-nav__link { + display: inline-block; + margin-top: 0 !important; +} + +.md-nav__item.md-nav__item--active > .guide-page-number { + color: var(--colors-white); + background: var(--md-typeset-a-color); +} + +.md-nav__item:not(.md-nav__item--nested)::before { + content: ''; + position: absolute; + top: 1.2rem; + left: 24px; + width: 0; + height: calc(100% - 18px); + border-left: 1px solid var(--md-default-fg-color--light); +} + +.md-nav__item:not(.md-nav__item--nested):last-child::before { + border-left: none !important; +} + +.md-nav__item.md-nav__item--nested > .md-nav__link { + display: flex; +} diff --git a/en/theme/material/assets/css/quick-start.css b/en/theme/material/assets/css/quick-start.css index 6c6f1c07cf..0ca853639a 100644 --- a/en/theme/material/assets/css/quick-start.css +++ b/en/theme/material/assets/css/quick-start.css @@ -112,7 +112,7 @@ ul.tick-list > li:before { line-height: 1.1; } -.md-nav__list { +.md-nav--secondary .md-nav__list { margin-top: .7rem; } @@ -126,10 +126,10 @@ ul.tick-list > li:before { [data-md-component='toc'] .md-nav__link::before { content: ''; position: absolute; - top: .5rem; + top: .95rem; left: 0; width: 0; - height: calc(100% - 5px); + height: calc(100% - 20px); border-left: 1px solid var(--md-default-fg-color); } diff --git a/en/theme/material/assets/css/theme.css b/en/theme/material/assets/css/theme.css index be915a7749..9852a1a59e 100644 --- a/en/theme/material/assets/css/theme.css +++ b/en/theme/material/assets/css/theme.css @@ -114,6 +114,19 @@ .icon-color-4 { background-color: var(--icon-color-4-bg); } .icon-color-4 svg path { fill: var(--icon-color-4-fg) !important; } +[data-md-color-scheme=default] .md-typeset pre > .md-clipboard { + color: var(--md-default-bg-color--lightest); +} + +[data-md-color-scheme=default] .md-typeset pre:hover > .md-clipboard { + color: var(--md-default-bg-color--light); +} + +[data-md-color-scheme=default] .md-typeset pre > .md-clipboard:focus, +[data-md-color-scheme=default] .md-typeset pre > .md-clipboard:hover { + color: var(--md-accent-fg-color); +} + .md-typeset .tabbed-labels, .highlight span.filename { border-top-left-radius: var(--md-code-block-radius); @@ -341,14 +354,19 @@ height: 93vh; } -.md-sidebar--primary { - border-right: 1px solid var(--md-divider-color); -} - .md-main__inner { margin-top: 0px; } +.md-nav__link { + margin-top: .8em; +} + +.md-nav { + font-size: .6rem; + line-height: 1.3; +} + .md-sidebar--secondary .md-nav--secondary > ul ul > li { padding-left: 30px; font-size: 0.6rem; @@ -373,6 +391,49 @@ display: none; } +.md-nav__link-read_time { + font-size: 10px; + color: var(--md-default-fg-color--light);; + white-space: nowrap; + word-break: keep-all; + font-style: italic; +} + +.md-nav__link-read_time > .md-nav__link-read_check:after { + background-color: #00c853; + -webkit-mask-image: var(--md-admonition-icon--success); + mask-image: var(--md-admonition-icon--success); + content: ""; + height: .6rem; + -webkit-mask-position: center; + mask-position: center; + -webkit-mask-repeat: no-repeat; + mask-repeat: no-repeat; + -webkit-mask-size: contain; + mask-size: contain; + position: absolute; + width: .6rem; + display: none; + padding-left: 25px; + top: .82rem; +} + +.md-nav__link-read_time.visited > .md-nav__link-read_check:after { + display: inline-block; +} + +.md-typeset h1 > span { + font-size: 14px; + font-style: italic; + color: var(--md-default-fg-color--light); +} + +.tabbed-content.tab_with_no_code { + background: var(--md-default-fg-color--lightest); + padding: 0 20px 10px; + border-radius: 0 0 var(--md-code-block-radius) var(--md-code-block-radius); +} + /* Media query breakpoints $base_px: 16px; @@ -400,6 +461,10 @@ background-color: var(--md-default-bg-color); height: 4.2rem; } + + .md-sidebar--primary { + top: var(--md-header-min-height); + } } @media screen and (min-width: 76.25em) { diff --git a/en/theme/material/assets/js/theme.js b/en/theme/material/assets/js/theme.js index 9a4a8b5e6f..00894f3459 100644 --- a/en/theme/material/assets/js/theme.js +++ b/en/theme/material/assets/js/theme.js @@ -1,5 +1,5 @@ /** - * Copyright (c) 2023, WSO2 LLC. (https://www.wso2.com). + * Copyright (c) 2023-2024, WSO2 LLC. (https://www.wso2.com). * * WSO2 LLC. licenses this file to you under the Apache License, * Version 2.0 (the "License"); you may not use this file except @@ -18,19 +18,35 @@ const dropdown = document.querySelector('.md-header__version-select-dropdown'); -// Add a click event listener to the document -document.addEventListener('click', function(event) { - // Check if the click event target is outside of the dropdown - if (!dropdown.contains(event.target)) { - dropdown.classList.remove('open'); // Hide the dropdown - } -}); +if (dropdown) { + // Add a click event listener to the document + document.addEventListener('click', function(event) { + // Check if the click event target is outside of the dropdown + if (!dropdown.contains(event.target)) { + dropdown.classList.remove('open'); // Hide the dropdown + } + }); + + // Add a click event listener to the dropdown link + const dropdownLink = dropdown.querySelector('.dropdown-link'); -// Add a click event listener to the dropdown link -const dropdownLink = dropdown.querySelector('.dropdown-link'); + dropdownLink.addEventListener('click', function(event) { + event.preventDefault(); + event.stopPropagation(); // Prevent the event from propagating to the document + dropdown.classList.toggle('open'); // Toggle the "open" class + }); +} -dropdownLink.addEventListener('click', function(event) { - event.preventDefault(); - event.stopPropagation(); // Prevent the event from propagating to the document - dropdown.classList.toggle('open'); // Toggle the "open" class +// Add a class to tasb that has multiple child elements rather than a code block +document.querySelectorAll('.tabbed-content').forEach(tabbedContent => { + const tabbedBlocks = Array.from(tabbedContent.querySelectorAll('.tabbed-block')); + + // Check if each .tabbed-block has more than 1 child or if its immediate child is not .highlight + const shouldAddClass = tabbedBlocks.some(tabbedBlock => + tabbedBlock.children.length > 1 || !tabbedBlock.firstElementChild.classList.contains('highlight') + ); + + if (shouldAddClass) { + tabbedContent.classList.add('tab_with_no_code'); + } }); diff --git a/en/theme/material/partials/nav-item.html b/en/theme/material/partials/nav-item.html new file mode 100644 index 0000000000..8159eb03e6 --- /dev/null +++ b/en/theme/material/partials/nav-item.html @@ -0,0 +1,180 @@ + + + +{% macro render(nav_item, path, level) %} + + + {% set class = "md-nav__item" %} + + {% if nav_item.active %} + {% set class = class ~ " md-nav__item--active" %} + {% endif %} + + + {% if nav_item.children %} + + + {% if "navigation.sections" in features and level == 1 + ( + "navigation.tabs" in features + ) %} + {% set class = class ~ " md-nav__item--section" %} + {% endif %} + + +
  • + {% set expanded = "navigation.expand" in features %} + {% set active = nav_item.active or expanded %} + + + {% set checked = "checked" if nav_item.active %} + {% if expanded and not checked %} + {% set indeterminate = "md-toggle--indeterminate" %} + {% endif %} + + + + + + {% set indexes = [] %} + {% if "navigation.indexes" in features %} + {% for nav_item in nav_item.children %} + {% if nav_item.is_index and not index is defined %} + {% set _ = indexes.append(nav_item) %} + {% endif %} + {% endfor %} + {% endif %} + + + {% if not indexes %} + + + + {% else %} + {% set index = indexes | first %} + {% set class = "md-nav__link--active" if index == page %} + + {% endif %} + + + +
  • + + + {% elif nav_item == page %} +
  • + {% set toc = page.toc %} + + + + + + {% set first = toc | first %} + {% if first and first.level == 1 %} + {% set toc = first.children %} + {% endif %} + + + {% if toc %} + + {% endif %} + + {{ nav_item.title }} + {% if nav_item.meta and nav_item.meta.read_time %} + + {{ nav_item.meta.read_time }} + + + {% endif %} + + + + {% if toc %} + {% include "partials/toc.html" %} + {% endif %} +
  • + + + {% else %} +
  • + + {{ nav_item.title }} + {% if nav_item.meta and nav_item.meta.read_time %} + + {{ nav_item.meta.read_time }} + + + {% endif %} + +
  • + {% endif %} +{% endmacro %} + + +{{ render(nav_item, path, level) }} diff --git a/en/theme/material/partials/tabs.html b/en/theme/material/partials/tabs.html new file mode 100644 index 0000000000..6fb1022b7a --- /dev/null +++ b/en/theme/material/partials/tabs.html @@ -0,0 +1,37 @@ + + + +{% set class = "" %} + + + diff --git a/en/theme/material/templates/complete-guide.html b/en/theme/material/templates/complete-guide.html new file mode 100644 index 0000000000..f0d207d5ab --- /dev/null +++ b/en/theme/material/templates/complete-guide.html @@ -0,0 +1,169 @@ + + +{% extends "base.html" %} + +{% block styles %} + {{ super() }} + +{% endblock %} + +{% block container %} +
    +
    +
    +
    + {% if page.meta.heading %} +

    + {{ page.meta.heading }} + {% if page.meta.read_time %} +
    {{ page.meta.read_time }} + {% endif %} +

    + {% endif %} + + {{ page.content }} +
    +
    +
    +
    + + {% 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 %} +
    +
    +
    + + +{% endblock %} diff --git a/en/theme/material/templates/integrations.html b/en/theme/material/templates/integrations.html index 6d0366c513..56060fc238 100644 --- a/en/theme/material/templates/integrations.html +++ b/en/theme/material/templates/integrations.html @@ -38,7 +38,7 @@ {% endif %}

    {{ integration.name }}

    {% set description = integration.description %} - {% set description = description.replace('{{ config.extra.product_name }}', config.extra.product_name) %} + {% set description = description.replace('{{ product_name }}', config.extra.product_name).replace('{{product_name}}', config.extra.product_name) %}

    {{ description }}