diff --git a/docs/admin/lock/README.md b/docs/admin/lock/README.md index 70692e11ee0..425d3c76ef5 100644 --- a/docs/admin/lock/README.md +++ b/docs/admin/lock/README.md @@ -2,124 +2,82 @@ tags: - administration - lock - - authorization - - OPA - - open policy agent - - PDP - - PEP - - authz + - authorization / authz + - Cedar + - Cedarling --- # Jans Lock Overview -At a high level, Jans Lock enables domains to enforce security policies based on -real time OAuth data. - -The PDP can make a blazingly fast decision if it has **in RAM** all the -necessary data, policies, and keys. But how can we keep all that rapidly -changing OAuth token data in RAM? This is especially challenging if we have a -distributed network of APIs, with each microservice deploying the PDP as a -encapsulated "sidecar". Lazy loading of token data by the PDP via OAuth -introspection or database access is not performant enough for real-time -transactional authorization. - -Like a messaging client, a Lock Client gets update messages from Auth Server -for each OAuth token update event. A message contains the reference id of the -token, which enables the Lock Client to retrieve the token data from the -database, and push it into the PDP's memory or cache. You could say that Lock -aggressively initializes the PDP with token data. A Lock Client can also push -policies and keys into a PDP (if necessary). - -## Definitions: Authz Components - -Centralized policy management is a best practice for authorization for distributed -networks. If security policies are buried in the code of numerous applications, -they are hard to inventory and harder to update. For decades, application -security architects have conceptualized distributed authorization in line with +Lock provides a centralized control plane for domains to use [Cedar](https://www.cedarpolicy.com/en) +to secure a network of distributed applications and audit the activity of both people and software. + +Using a declarative syntax like Cedar for authorization policies is a best practice for enterprise +application security. Using a policy engine enables developers to define security in their +application without resorting to writing policies in the code. Cedar supports traditional access management strategies like RBAC, and more adaptive policies that consider a more nuanced model +of the context. The Cedar Engine does this without sacrificing the security benefit of a +deterministic policy engine. + +There are three key components in the Lock architecture: (1) Cedarling--a WebAssembly ("WASM") +component that runs the [Amazon Rust Cedar Engine](https://github.com/cedar-policy/cedar) and +performs JWT token validation; (2) Lock Master--a web service deployed by domains to manage a +network of distributed ephemeral Cedarlings; (3) [Agama Lab](https://cloud.gluu.org/agama-lab) +policy authoring tool for developers to easily design policies and publish their policy store +in Github. + +The Cedarling makes sense to secure even a single browser-based application. A developer could +specify a local Cedarling policy store or retreive one from a Web URI (e.g. Github). + +Jans Lock offers organizational control over a network of Cedarlings used for different +applications, each with their own policy store. It does this by providing central endpoints that +publish configuration, collect audit logs, and push real time updates to Cedarlings. In addition to +publishing the Policy Store, the Lock Master server enables Cedarlings to subscibe to real time +event notifications. A notification example is the latest OAuth Token Status List JWT from Jans +Auth Server, or an updated Policy Store. + +## Background + +For years, security architects have conceptualized distributed authorization model in line with [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2904#section-4.4) and [XACML](https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cos01-en.html), -which describe several common components: +which describe several common roles: + +| Role | Acronym | Description | +| ----- | :--: | ----------- | +| Policy Decision Point | PDP | Service which evaluates access requests against authorization policies before issuing access decisions | +| Policy Information Point | PIP | The source of "data", e.g. about people, clients and resources | +| Policy Enforcement Point | PEP | Service, website or API which queries the PDP for authorization | +| Policy Administration Point | PAP | Where admins manage the authorization infrastructure | +| Policy Retrieval Point | PRP | Repository where policies are stored | + +Jans Lock aligns with this model: -|Abbr. | Term | Description | +| Role | Lock | Description | | ----- | :--: | ----------- | -| PDP | Policy Decision Point | Service which evaluates access requests against authorization policies before issuing access decisions | -| PEP | Policy Enforcement Point | Service, website or API which queries the PDP for authorization | -| PAP | Policy Administration Point | User interface where admins manage authorization policies | -| PIP | Policy Information Point | The "data" about people, clients and resources | -| PRP | Policy Retrieval Point | Repository where policies are stored | - -## Lock Design Goal - -In the old days of "WAM" (web access management), each web server would query -a centralized PDP over the network. This is ok for course grain authorization. -But for fine grain authorization, it is too slow--each decision requires a round -trip HTTP request/response. A more performant design is to move the PDP to the -edge of the network. Policy definition and administration is still a centralized -activity. Once a policy is defined, it can be executed anywhere on the network. -Although multiple PDP instances exist, they must provide the same access control -decisions given the same inputs. - -Another critical optimization was to move the PIP to the edge, so the PDP -has all the data it needs to make a decision. This aligns with a principle that -each microservice has all logic and data encapsulated into a single -deployment unit. - -![1990s WAM v. 2020s Cloud Native](../../assets/lock-wam-v-cloud-native-authz.png) - -## Choose your PDP or use OPA - -Lock has a plugin architecture to support different PDP solutions. Janssen -provides a default PDP: [OPA](https://openpolicyagent.org), a -[CNCF](https://cncf.io) governed project. OPA is a popular PDP, whose adoption -grew significantly in response to the need for granular policies for Kubernetes -access control. If you have a different PDP, you can write a -[Lock PDP Plugin](./lock_pdp_plugin.md). - -## Get Started - -The Jans Lock solution pushes OAuth token data from Auth Server to a PDP, -enabling authorization based on real time information from the OAuth -infrastructure. In order to use Lock, admins will have to do a few things: - - * [Enable Lock in Auth Server](./lock_auth_server_config.md) - * [Configure a Lock Client instance](./lock_client_config.md) - * [Configure A PDP](./lock_opa.md) - -The Auth Server token stream contains only the reference ids of new, updated, or -revoked tokens. Lock retrieves the data (i.e. token value) for a given token -reference id from the database service. This design minimizes the traffic on the -message queue and leverages cloud database topologies. Lock Clients can -optionally retrieve policies from Github or public keys from one or more JWKS -endpoints. - -![Lock Data Flow Communication Overview](../../assets/lock-design-diagram-01.png) - -This architecture results in the best of three worlds. First, authorization is -blazing fast, because OAuth access and transaction tokens are in OPA's memory-- -no introspection is needed. Second, admins can use their PDP to express -complex policies based on any combination of data present in the token or -context. Third, domains can publish central data for local decision making, for -example information about how the end user authenticated. - -The Auth Server Lock token stream is highly confidential. Lock must present a -valid OAuth access token to Auth Server in order subscribe to the token -stream. Domains should only use Lock for trusted first party services with -a private network. Each Lock Client instance uses OAuth dynamic client -registration with a software statement to enable asymmetric client -authentication and DPoP access tokens. - -The diagram below illustrates a Jans Lock topology where the OPA PDP is used to -control course grain authorization in an API gateway, fine grain authorization -in First Party API code, and the issuance of access token scopes. - -![North-South API Gateway Authz with Lock](../../assets/lock-north-south-api-gateway-diagram.png) - -This authorization model is also useful for East-West service mesh authorization -because it avoids the "hairpin" inefficiency of routing all traffic through -and API gateway (which is better for North-South web ingress). TLS is required -to protect the bearer token. MTLS is better if the extra effort for additional -transport security is justified. - -![East-West Service Mesh Authz with Lock](../../assets/lock-east-west-service-mesh-diagram.png) - -[Next](./lock_auth_server_config.md) +| PDP | Cedarling | Evaluates policies versus input data | +| PIP | JWT tokens | Contain data to instantiate entities | +| PEP | Application | Must rely on Cedarling for decision | +| PAP | Jans Config API | Endpoints for Lock admin configuration | +| PRP | Lock Master | Endpoints to publish Policy Store and other PDP configuration | + +## Lock Design Goals + +Following are a list of goals that informed the design of Jans Lock and the Cedarling: + +* Move the PDP to the edge of the network--even into the browser itself. +* Make the PDP performant and deterministic (i.e. milliseond statup time and always return a + PERMIT/DENY response). +* Empower application developers to author policies appropriate for the resources and actions +they need to protect. +* Centralilze audit and health data collection +* Publish centralized updates enabling the network to adapt in real time to attacks +* Push updates to enable near-realtime responses to attacks + +# More information + +* Lock Master configuration and operation [docs](./lock-master.md) +* Cedarling [Readme](.) +* RBAC Use Case +* API Access Management Use Case +* Real time token revocation Use Case +* Cedarling [Training](.) (coming soon!) diff --git a/docs/admin/lock/lock-master.md b/docs/admin/lock/lock-master.md new file mode 100644 index 00000000000..5f00f673e7f --- /dev/null +++ b/docs/admin/lock/lock-master.md @@ -0,0 +1,2 @@ +# Lock Master + diff --git a/docs/admin/lock/lock_auth_server_config.md b/docs/admin/lock/lock_auth_server_config.md deleted file mode 100644 index 218f3b057da..00000000000 --- a/docs/admin/lock/lock_auth_server_config.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -tags: - - administration - - lock - - opa ---- - -## Jans Lock Token Stream Service - -To enable Jans Auth PubSub messages 2 configuration should be configured: - * Lock messaging connection details - * Jans Auth messaginbg configuration - -It's possible to modify them with jans-config-api. - -First configuration Jans stores in `ou=configuration,o=jans` entry. This is reusable configuration. Other application which uses `jans-core-message.jar` library also should use it. -Default configuration after CE install when messaging API is not enabled: - -``` -jansMessageConf: -{ - "messageProviderType": "DISABLED", - "postgresConfiguration": { - "connectionUri": "jdbc:postgresql://localhost:5432/postgres", - "dbSchemaName": "public", - "authUserName": "postgres", - "authUserPassword": "", - "messageWaitMillis": 100, - "messageSleepThreadTime": 200 - }, - "redisConfiguration": { - "servers": "localhost:6379" - } -} -``` - -It has 2 section for PostgreSQL (`postgresConfiguration`) and Redis (`redisConfiguration`) connection details. - -`messageProviderType` can have 3 values: DISABLED, REDIS, POSTGRES - -Full list of properties defined in jans-config-api-swagger.yaml. - - -Second configuration is needed for Jans Auth. In current version Jans Auth calls message API after access_token persistence/removal from/to DB from `GarntService`. Jans Messages API library provides generic API to hide actual PubSub messages publishing/receiving implementation. - -This is default configuration after server install: - -``` - "lockMessageConfig": { - "enableTokenMessages" : false, - "tokenMessagesChannel": "jans_token" - } -``` -First property control sending messages to PubSub server. Second one `tokenMessagesChannel` specify channel name to send token messages. - -The format of messages which Jans Auth issue is JSON. And it has minimum data for quick processing. Here is message pattern: - -``` -{"tknTyp" : "access_token", "tknId" : "token_identifier", "tknOp" : "add/del"} -``` - -Note: For demo purposes in Jans CE with PostgreSQL and Lock server selected to install messages enabled by default. - - -List of Lock flows: - -![Combined diagram](../../assets/lock-flows.png) -[Link](https://sequencediagram.org/index.html#initialData=C4S2BsFMAIBkHsDGBrax7MgO2gM3PAO4DOAUKQIaLoBO0ACpDcfFqQA4U2iIidbBoAJXocuPPhQHQAggFdgAC2gBlJgDcmY7iF79B9OQCMVx7RP0MAIqM469UwVYBC5XK2C4KAWxDgAntDerPDkAOY08HLs0ACMAHTC9HgEhKSMzKwAtAB8IgBcsgqKAHLQAGRFSgBapCIAPLnySqoaTIXxnaTNymo0mjS5hibGhcPgIMTKU-DcQZDExBRhkIUA3gBEwMhYACr+7BvQhRtUiAvEAPromFgbADTQWzsAkgAmRyc32JeI8G+QB5PbZYADyh2OTwobw+AF80PBoMR2JBeLgQJA3tBEIopFhIOBSNg3uFItFoAAmRIIFAI27EaDRN4UYCQdLGUxGXI05CFADCrGIcm8MBFi2WMFwkW82NxWHx4GgUixdmIMDApB5jRyLkKCGhdOw0CMgRBfIBmqQyG1PLGNEgdhgzOAFGg2GANEC7jo9Bs0EIYGmfxRj0Q9pZIFYVhZkEekAAHuwQDQI1GY485GqaO9QxN3e9LSgbVb+RRwIqE6yaFgy0iw3xBOglTCgrMYCyPSAjAoFgjoM7Xe7PYXrUMbKXy9ZkjJ6C8+2qsFiB9AQAJERqtdyS6ocZi5FBDThEFApIyYqwV4IE0mU6BWETF6SojEAMzUq3Yk84cnX5OY42QN6MDIqiIDov+zpsj0rT9EwQwcqMDDGBMUyHm6iZ-liMxzGKSwrNAmwgvsEInGcFzXBg2BAs8WDvJ8wKUVgvz-ICjw0eC9EbAC4AbPCTYgWiGJYjieIEuyIxcjktrQAKWBCiK8zivhUrwDKInygSSqLtAqrqsAI7FigE4VvGVY1oqxD1uwghGIBbZocekCntEBljvQxlTrIs59vawSaP2LKuipMoasST7kgALO+tLsPAEy8L2TIxq5UnbgAYpAwA4m6AyBC+AAMSKoqwbwMrF8UYgywVIiign-ihgjwLg0AAKpCC8DLKtAExYMgDJNtUfAMgAFGEgYUEYOmRAAVqighcDiICaAAlCl0l8mWJlmbWlk0A2fZJayOlxbolUAUB2KbauYRTiObmFDIMIAPS+fA-nlQlZBhaQETPtAACsiT0AAosk+BEOkoP3a02kAI5yEw-jpDYQyg4UQgLLFcntrgVbQPDiM5WWcipmwxJAA) - - -Code: - -``` -title Lock token flows - -actor Person -participant RP -participant Auth Server -participant PubSub -participant PDP -participant DB - -fontfamily mono - -group 1. RP flow -Person->RP: AuthN & AuthZ -RP<->Auth Server: ... -Auth Server->PubSub: Publish short message: {"tknTyp" : "access_token", "tknId" : "token_code", "tknOp" : "add"} to specified channel -end - -group 2. Lock tokens update -PubSub->Lock: Consume message from channel and parse it -Lock<->DB: Load token by tknCde -Lock<->Lock: Prepare data entry for PDP with scope, creationDate, expirationDate, userId, clientId -Lock<->Lock: Call external script to add more attributes to data entry -Lock<->PDP: Call PDP API to send data into it -Lock<->Lock: Schedule token clean up on it expiration -end - -group 3. Lock clean up expired before specified date -Auth Server->PubSub: Publish token expired short message {"tknTyp" : "access_token", "tknId" : "token_code", "tknOp" : "del"} to specified channel -PubSub->Lock: Consume message from channel and parse it -Lock<->Lock: Call external script before token clean up -Lock<->PDP: Call PDP API to remove data from it -end - -group 4. Lock policies update -Lock<->Lock: Fetch every 30 seconds policies from specified list of URIs and links to Zips (githab project archive) -Lock<->Lock: Call external script to update policies before calling PDP -Lock->PDP: Add/remove polcies -end - -group 5. PEP flow -PEP->PDP: Send query -PDP->PEP: Response after query evaluation -end -``` \ No newline at end of file diff --git a/docs/admin/lock/lock_client_config.md b/docs/admin/lock/lock_client_config.md deleted file mode 100644 index 10cfe1fff42..00000000000 --- a/docs/admin/lock/lock_client_config.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -tags: - - administration - - lock - - opa ---- - -## Lock Client - -Lock client is Jans Message API consumer. This is middle point of join all Lock parts together. This part can be deployed as server or service. It subscribes to specified channels, process messages, send data to OPA or other PDP, send policies to OPA or other PDP and allows to customize data which server send to PDP with custom scripts. - -Lock client has 2 deployment models. It can be deployed as separate server or as Jans Auth server plugin. Second method is recommended deployment method for cloud deployment. It allows to reduce memory needed for both services. In this method Jans Lock added as plugin to Jans Auth as custom library. -All functionality is the same in both deployment modes. - -Since Lock is separated server it has own configuration in `ou=jans-lock,ou=configuration,o=jans` - -The main part of it is generic for all Jans projects. These parts have Lock specific properties: - -``` - "tokenChannels":[ - "jans_token" - ], - "opaConfiguration": { - "baseUrl" : "http://localhost:8181/v1/", - "accessToken" : "" - }, - - "policiesJsonUris": [ - ], - "policiesJsonUrisAccessToken" : "", - - "policiesZipUris": [ - ], - "policiesZipUrisAccessToken" : "", - - "messageConsumerType": "OPA", - "policyConsumerType": "OPA" -``` - -"tokenChannels" – list of token channel names. It’s array to allows add more token types in future without changing property type. Now it has only one value “jans_token”. - -"opaConfiguration" section has 2 properties to define OPA API base URL and specify OPA Bearer access token if OPA server started with it. - -Next properties "policiesJsonUris" and "policiesZipUris" specify sources which Lock should check periodically to get new PDP policies. There are more details is in [OPA](./lock_opa.md) section. This service runs periodically with 30 seconds interval. - -`messageConsumerType` and `policyConsumerType` specify PDP for data and PDP for policies. In most cases both should specify same provider. Different types can be used together with extension script to put for example data in few different PDP. - -Lock is not strictly depends on OPA. It’s possible to override OPA with custom script or use another PDP provided in custom jar. There are more details is in [Lock PDP plugin](./lock_pdp_plugin.md) section. - -There is no limitation for count of Lock client instances. Each Lock instance subscribes to specified in configuration PubSub server and receive messages. - -Extension script has next methods: - -``` - void beforeDataPut(Object messageNode, Object dataNode, Object context); - void beforeDataRemoval(Object messageNode, Object context); - - void beforePolicyPut(String sourceUri, List policies, Object context); - void beforePolicyRemoval(String sourceUri, Object context); -``` - -`Object context` in methods is instance of [xternalLockContext](https://github.com/JanssenProject/jans/blob/main/jans-core/script/src/main/java/io/jans/model/custom/script/type/lock/LockExtensionType.java) -`Object messageNode` is JsonNode instance with message received from PubSub -`Object dataNode` is ObjectNode instance with data message for PubSub - -`ExternalLockContext` contains loaded `TokenEntity` from DB. Also it has 2 properties to control flow execution `cancelPdpOperation` and `cancelNextScriptOperation` - -Since it’s possible to add more than one custom script context property `cancelNextScriptOperation` allows to stop executing next script after current script execution. -Another flow property `cancelPdpOperation` allows to override default data/policy update rules. If script set this property to `true` this means that it should be responsible of adding data/policies into PDP. - -Data expiration Lock do automatically. For this it uses expiration stored in DB. Also it can do immediate expiration on remove data PubSub message. - -Lock sends only few token attributes to OPA to save memory. Default data entry which Lock send to PDP contains next attributes: `scope`, `creationDate`, `expirationDate`, `userId`, `clientId`. It’s possible to customize attributes which Lock send to PDP from script. diff --git a/docs/admin/lock/lock_installation.md b/docs/admin/lock/lock_installation.md deleted file mode 100644 index abfaeef6afb..00000000000 --- a/docs/admin/lock/lock_installation.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -tags: - - administration - - lock - - installation - - opa ---- - -# Lock Installation - -This document details the steps required to set up a main Jans AS running lock -as a service, and a lock client. - -## Helm Deployments - -This section is a work in progress. - -## VM Installation - -!!! warning - VM installations are not recommeded for production deployments. - -For the purpose of this document, we are using a VM installation -with PostgreSQL persistence and [OPA](https://www.openpolicyagent.org/) as PDP. - -## Install Lock and OPA on Janssen Server - -The authorization server acts as the source of token data for all lock clients. - -- Follow the Jans AS setup instructions as documented [here](https://docs.jans.io/head/admin/install/) - - When choosing persistence, select local PostgreSQL -- When prompted for `Jans Lock [No]`, select `Yes` -- Select the option to install `Jans Lock as service`. This will add lock as a -plugin to the authorization server -- When prompted to install OPA, select `Yes` - -## Install Lock Client - -The Lock client acts as a medium by which an application can get token -information from the auth server in real time. - -In this setup, the Lock client -is installed as a jetty server with OPA running alongside it. This client -can be queried by any application that needs to make authorization decision. -For example, a Flask API -running on the same server can query OPA for token details coming in from the -auth server. - -To install Janssen Lock Client, you need a main Janssen Server. For the purpose -of this document, let us assume that persistence used is PostgreSQL. - -1. Obtain salt by executing the following command on Janssen Server - ```shell - cat /etc/jans/conf/salt - ``` - Output will look like: - ```text - encodeSalt = Qm0MCPh20QGsE21ZovVnUIb8 - ``` - This is a 24 character string used to encode/decode secret data. - -1. Obtain the decrypted password for PostgreSQL by executing the following command on Janssen Server - ```shell - cat /opt/jans/jans-setup/setup.properties.last | grep rdbm` - ``` -1. Enable remote connections to PostgreSQL on your main server - - 1. Run this command as root to find the configuration fileee - ```shell - su - postgres -c 'psql -U postgres -d postgres -t -c "SHOW config_file;"' - ``` - - 2. Edit the configuration file, uncomment the line containing - `listen_addresses` and edit it to `listen_addresses = '*'`. - This will allow PostgreSQL to listen on all network interfaces. - You should take precautions accordingly, such as setting up firewalls. - - 3. Run this command as root to find the client authentication configuration file: `su - postgres -c 'psql -U postgres -d postgres -t -c "SHOW hba_file;"'` - - 4. Add the following line - ```text - host jansdb jans 0.0.0.0/0 md5 - ``` - - 5. Save the file, and restart PostgreSQL - ```shell - systemctl restart postgresql - ``` - -- Download the lock installer - ```shell - wget https://raw.githubusercontent.com/JanssenProject/jans/main/jans-linux-setup/jans_setup/install.py - ``` -- Run the installer - ```shell - python3 install.py --lock-setup - ``` -- When prompted, enter the salt, and the main server's PostgreSQL details. -- Once setup is complete, verify status of lock client by visiting `http:///jans-lock/sys/health-check` diff --git a/docs/admin/lock/lock_opa.md b/docs/admin/lock/lock_opa.md deleted file mode 100644 index 3c1548f0f11..00000000000 --- a/docs/admin/lock/lock_opa.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -tags: - - administration - - lock - - opa ---- - -## Jans Lock Rego Policies - -Lock can update your policies from a GIT or URI based policy store. - -Remote files specified in `policiesJsonUris` array should be JSON array with list of actual policies URIs. This behavior was added to group properties in packages. - -`policiesZipUris` is another way to get policies. This can be also be link to download github repository as zip archive. - -These 2 methods support files download with `Bearer` authentication protection. Access tokens can be specified in `policiesJsonUrisAccessToken` and `policiesZipUrisAccessToken` - -Lock automatically do policies clean up if they were removed from source servers or configuration on next synchronization. - diff --git a/docs/admin/lock/lock_pdp_plugin.md b/docs/admin/lock/lock_pdp_plugin.md deleted file mode 100644 index 1d777606f11..00000000000 --- a/docs/admin/lock/lock_pdp_plugin.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -tags: - - administration - - lock - - opa ---- - -# Developer Guide: Lock PDP Client - -## Janc core messages API - -Jans provides `jans-core-message` library to work with PubSub servers. It has minimum dependencies and can be integrated in other projects. Current implementation supports 2 servers PostgreSQL and Redis. - -To work with PostgreSQL/Redis servers it has [MessageInterface](https://github.com/JanssenProject/jans/blob/main/jans-core/message/src/main/java/io/jans/service/message/provider/MessageInterface.java)/[MessageProvider](https://github.com/JanssenProject/jans/blob/main/jans-core/message/src/main/java/io/jans/service/message/provider/MessageProvider.java) implementations. It has methods to subscribe and publish messages defined in: - -``` -public abstract class MessageProvider implements MessageInterface { - - /* - * Delegate internal connection object - */ - public abstract T getDelegate(); - - public abstract MessageProviderType getProviderType(); - - public abstract void shutdown(); - -} - -public interface MessageInterface { - - void subscribe(PubSubInterface pubSubAdapter, String... channels); - - void unsubscribe(PubSubInterface pubSubAdapter); - - boolean publish(String channel, String message); - -} - -``` - -All methods defined in this interface `MessageInterface` are asynchronous. -`MessageProvider` provides additional methods needed to determine it type and handle correct shutdown. - -[PubSubInterface](https://github.com/JanssenProject/jans/blob/main/jans-core/message/src/main/java/io/jans/service/message/pubsub/PubSubInterface.java) here defines call back class which API should call on messaging events: - -To add new PubSub support library should add new `MessageProvider` implementation. - -``` -public interface PubSubInterface { - - void onMessage(String channel, String message); - - void onSubscribe(String channel, int subscribedChannels); - - void onUnsubscribe(String channel, int subscribedChannels); - -} -``` - -## New PDP support - - -To add new PDP support jar file should has 2 classes implementation: `MessageConsumer` and `PolicyConsumer`. Lock has 2 implementations of these interfaces [OpaMessageConsumer](https://github.com/JanssenProject/jans/blob/main/jans-lock/service/src/main/java/io/jans/lock/service/consumer/message/opa/OpaMessageConsumer.java) and [OpaPolicyConsumer](https://github.com/JanssenProject/jans/blob/main/jans-lock/service/src/main/java/io/jans/lock/service/consumer/policy/opa/OpaPolicyConsumer.java). After adding jar with new PDP support Lock should automatically find these implementations at startup. - -``` -public abstract class MessageConsumer implements MessageConsumerInterface { - - public abstract String getMessageConsumerType(); - - public abstract void destroy(); - -} - -public interface MessageConsumerInterface extends PubSubInterface { - - public boolean putData(String message, JsonNode messageNode); - -} - -``` - -Reference implementation for OPA is [OpaMessageConsumer](https://github.com/JanssenProject/jans/blob/main/jans-lock/service/src/main/java/io/jans/lock/service/consumer/message/opa/OpaMessageConsumer.java). It subscribes to message channels and send data to OPA through Rest API. - -``` -public abstract class PolicyConsumer implements MessagePolicyInterface { - - public abstract String getPolicyConsumerType(); - - public abstract void destroy(); - -} - -public interface MessagePolicyInterface { - - public boolean putPolicies(String sourceUri, List policies); - - public boolean removePolicies(String sourceUri); - -} -``` - -Reference implementation for OPA is [`OpaPolicyConsumer`](https://github.com/JanssenProject/jans/blob/main/jans-lock/service/src/main/java/io/jans/lock/service/consumer/policy/opa/OpaPolicyConsumer.java). `PolicyDownloadService` calls this service to send updates to OPA through Rest API. diff --git a/docs/assets/lock-design-diagram-01.png b/docs/assets/lock-design-diagram-01.png deleted file mode 100644 index 36f4607adf9..00000000000 Binary files a/docs/assets/lock-design-diagram-01.png and /dev/null differ diff --git a/docs/assets/lock-east-west-service-mesh-diagram.png b/docs/assets/lock-east-west-service-mesh-diagram.png deleted file mode 100644 index aefe53e18b1..00000000000 Binary files a/docs/assets/lock-east-west-service-mesh-diagram.png and /dev/null differ diff --git a/docs/assets/lock-flows.png b/docs/assets/lock-flows.png deleted file mode 100644 index 5b5ca420df6..00000000000 Binary files a/docs/assets/lock-flows.png and /dev/null differ diff --git a/docs/assets/lock-north-south-api-gateway-diagram.png b/docs/assets/lock-north-south-api-gateway-diagram.png deleted file mode 100644 index 7ebfac26c65..00000000000 Binary files a/docs/assets/lock-north-south-api-gateway-diagram.png and /dev/null differ diff --git a/docs/assets/lock-wam-v-cloud-native-authz.png b/docs/assets/lock-wam-v-cloud-native-authz.png deleted file mode 100644 index e27641c3e75..00000000000 Binary files a/docs/assets/lock-wam-v-cloud-native-authz.png and /dev/null differ