# risesoft-y9/Digital-Infrastructure: a three-role admin platform for government and enterprise SSO, org charts and permissions

> Digital-Infrastructure is a Spring Boot and Vue 3 management platform that splits administration into three accounts, ships an OAuth2 single sign-on server, and hands application permissions out through roles, posts and data catalogues. It is built for large, distributed deployments, and it assumes you already run Nacos, Redis, Kafka and a database.

**risesoft-y9/Digital-Infrastructure** — 数字底座是一款面向大型政府、企业数字化转型，基于身份认证、组织架构、岗位职务、应用系统、资源角色、数据目录、安全控制等功能构建的统一且安全的管理支撑平台。数字底座基于三员管理模式，具备微服务、多租户、容器化和国产化，支持用户利用代码生成器快速构建自己的业务应用，同时可关联诸多成熟且好用的内部生态应用。

- Repository: https://github.com/risesoft-y9/Digital-Infrastructure
- Website: https://www.risesoft.net/
- Stars: 2,612 · Forks: 443
- Language: Java
- License: GPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/risesoft-y9-digital-infrastructure

## What Digital-Infrastructure solves, and the organisations it assumes

Most internal platforms end up with one administrator account that can do everything. Digital-Infrastructure takes the opposite position. It is a management base for identity, organisation structure, posts, application systems, resource roles, data catalogues and security control, and its defining design choice is the three-role model: a system administrator, a security officer and a security auditor, each with a different set of screens. The system administrator builds the console, the organisation tree and the application resources. The security officer binds roles to menus and buttons, grants resources by organisation, post and role, and reads the logs of ordinary users. The security auditor reads the logs of the other two. No single account holds both the power to change permissions and the power to audit them, which is the point.

The audience is narrow and the README says so: large government and enterprise digital transformation programmes, run in cloud tenant mode, scaled out as microservices. A team of three building a SaaS dashboard is not the target. A provincial department or a company with several subsidiaries, each needing its own sub-domain three-role structure, is. The README describes sub-domain three-role management for child and second-level organisations, and the security officer can authorise those sub-domain accounts. That is the feature that separates this from a generic RBAC library.

## How the three-role permission model actually flows

The data flow starts with structure, not with users. The system administrator creates posts under an organisation and department tree, then creates application systems with multi-level directories beneath them, then defines application resources, which the README describes as menus and buttons, with free definition of internal resources. Roles come next: application roles belong to a system, public roles sit outside every system. Only then does the security officer connect the two sides, binding roles to resources and granting resources to organisations, posts and roles. A permission tree exposes the result in both list and tree form, so you can see which resources and roles any person holds.

Data catalogues follow a parallel path. They are catalogued as a tree of organisation departments, data classifications and time-period templates, and the security officer grants catalogues to organisations, posts and roles. So there are two authorisation dimensions in the same product: application resources, which control what screens and buttons a user sees, and data catalogues, which control what data they may reach. That separation is the most interesting part of the design, and the README does not explain how the two are enforced together at request time. The starter list includes a permission component, risenet-y9boot-starter-permission, but the README does not document its request-level behaviour, so treat the enforcement layer as something you will read from the source.

## Installing Digital-Infrastructure and reaching the console

The README gives no step-by-step install commands. It points to the source repository and to an online demo, and the deployment diagram states that the platform can be deployed in containers and scaled out as microservices, that the single sign-on server must be deployed separately, and that a single instance in a domestic (信创) environment with 4 cores and 8 GB of memory can handle 2000 users. That last figure is the project's own claim about a single instance, not a benchmark you should generalise from.

What the repository layout does tell you is the shape of a build. The project is a Maven multi-module build, so the entry point is the root pom.xml. A first compile looks like this:

```bash
git clone https://github.com/risesoft-y9/Digital-Infrastructure.git
cd Digital-Infrastructure
mvn clean install -DskipTests
```

The modules build in dependency order, and the README's directory listing names the three runnable services under y9-digitalbase-module: y9-module-platform for the backend, y9-module-log for logging and y9-module-sso for the authentication server. The deployment diagram states that the SSO server is deployed on its own, so start it separately from the platform. Because the README documents no run command, no ports and no environment variables, the only reliable next step is to read the configuration files inside each module and the example projects, which are named for exactly the integrations you will need: risenet-y9demo-sso-oauth2 for the OAuth2 flow, risenet-y9demo-kernel-api for calling the platform, and risenet-y9demo-sync-kafka for pushing organisation data over Kafka.

## The modules you will actually touch

The repository splits into five families. y9-digitalbase-common holds shared models, Nacos encryption, SQL DDL utilities, tenant dynamic datasource and properties. y9-digitalbase-starter holds the auto-configuration pieces: Redis cache, Elasticsearch, id generation, JPA for public, dedicated and tenant databases, Liquibase schema versioning, Kafka publish and consume, OpenFeign, permission, security, OAuth2 resource and web MVC. y9-digitalbase-support holds file storage with local, FTP and REST backends, plus entity audit history. y9-digitalbase-module holds the running services: y9-module-log, y9-module-platform and y9-module-sso. y9-digitalbase-example holds nine demo projects, one each for Redis, JPA, Elasticsearch, file service, unified code, kernel API, log reporting, OAuth2 and Kafka-based organisation sync.

The example module is the fastest way to understand the platform without reading the whole codebase. If you want to see how organisation data is pushed to another system, risenet-y9demo-sync-kafka shows the Kafka message mechanism. If you want to call the platform from your own service, risenet-y9demo-kernel-api shows the API calls, and risenet-y9demo-sso-oauth2 shows the OAuth2 flow. The README does not describe the example projects beyond their names, so expect to read code rather than documentation.

## Where Digital-Infrastructure is the wrong tool

The first limitation is operational weight. The topic list and the starter modules together imply Nacos for configuration, Redis for caching, Kafka for messaging, Elasticsearch for full-text search and a relational database under JPA, plus a separately deployed SSO server. That is five or six moving parts before you have written a line of business logic. For a team without existing infrastructure, the cost of running this platform exceeds the cost of writing a simpler permission model.

The second is the documentation gap. The README is thorough about what each screen in the three-role console does and thin about how to install or upgrade. There are no documented upgrade steps between v9.6.5, v9.6.6 and v9.6.7, and no rollback procedure. Liquibase is present as a schema versioning component, which suggests migrations are handled at the database level, but the README does not explain the migration sequence. If you adopt this, you own the upgrade path.

The third is version ambiguity. The README badges say Spring Boot 2.7 and JDK 11, while the repository topics include springboot3 and the version badge says v9.6.9, which is newer than the latest listed release, v9.6.7 from 2024-12-30. The README does not reconcile these. Check the actual pom.xml files before you plan a runtime.

## How it differs from Keycloak plus an admin framework

The obvious alternative is to assemble the pieces yourself: Keycloak or another OAuth2 provider for identity, plus a general admin framework for organisation and menu management. The difference is where the permission logic lives. An identity provider knows users, groups and clients; it does not know that a post inside a department inside a subsidiary should receive a specific menu button and a specific data catalogue. Digital-Infrastructure puts that whole chain in one model, and adds the three-role split on top, so the person who grants permissions is not the person who reviews the audit log.

Keycloak, by contrast, is a general-purpose identity server with a mature administration console and a much larger community. If your requirement is federation, social login or standards breadth, it is the stronger choice, and Digital-Infrastructure's own README notes that you can connect other single sign-on systems instead of the built-in one. What you would then have to build yourself is the organisation, post, application resource and data catalogue layers, which is exactly the work this project has already done. The trade is a heavier stack in exchange for a permission model that matches how large public-sector organisations are actually structured.

## Licence and the cost of staying current

The licence is GPL-3.0. That matters for distribution: if you ship a modified version to third parties, the copyleft terms apply to the combined work, and the README does not offer a commercial or dual-licence option. Internal deployment inside one organisation is a different question from distributing a product built on top of it, and the answer depends on your own legal position, so take advice rather than treating this paragraph as guidance.

On maintenance, the repository is not archived and the last push was on 2026-09-22, which is recent. The release cadence is slower: v9.6.5 and v9.6.6 both landed on 2024-09-05, and v9.6.7 on 2024-12-30. So commits continue while tagged releases are infrequent. Upgrading means tracking the main branch or waiting for a tag, and since the README documents no migration procedure, you should expect to read the Liquibase changelogs yourself before moving a production instance. Budget for that work: a platform with this many modules is not something you upgrade casually on a Friday.

## Conclusion

Adopt Digital-Infrastructure if you are building an internal platform for a large organisation and you need a ready-made three-role permission model, an OAuth2 server and a code generator for your own business modules. Do not adopt it if you want a small self-contained admin panel, if GPL-3.0 is a problem for your distribution plan, or if you cannot run Nacos, Redis, Kafka and Elasticsearch alongside it, because the repository layout shows those as separate components rather than optional extras. Before committing, verify the exact versions of Nacos, Redis and Kafka that the v9.6.7 release expects, check whether the Spring Boot 2.7 and JDK 11 combination in the README matches the Spring Boot 3 topic in the repository metadata, and confirm that the SSO server is deployed as its own service, since the deployment diagram states it must be installed separately.

## FAQ

### What is Digital-Infrastructure from risesoft-y9?

It is a unified management platform for large government and enterprise digital transformation, covering identity authentication, organisation structure, posts, application systems, resource roles, data catalogues and security control. It is built on a three-role administration model and supports microservices, multi-tenancy, containerisation and domestic (信创) environments.

### What are the three roles in Digital-Infrastructure and what does each do?

The system administrator builds the console, organisation structure and application resources. The security officer binds roles to resources, grants resources and data catalogues by organisation, post and role, and reviews ordinary user logs. The security auditor reviews the logs of the system administrator and the security officer.

### Which technologies does Digital-Infrastructure require?

The repository is a Maven multi-module Java project with a Vue 3 front end, and the starter modules cover Redis, Elasticsearch, Kafka, Nacos, OpenFeign, Liquibase and JPA. The README badges list Spring Boot 2.7, JDK 11 and Vue 3.3, while the repository topics also mention Spring Boot 3, so verify the versions in the pom files.

### What licence does Digital-Infrastructure use?

The README badge and the LICENSE file identify GPL-3.0. The README does not mention a commercial or dual-licence option, so redistribution of a modified version is subject to the copyleft terms.

## Sources

- [License: GPL-3.0](https://github.com/risesoft-y9/Digital-Infrastructure/blob/main/LICENSE)
- [Project website](https://www.risesoft.net/)
- [README](https://github.com/risesoft-y9/Digital-Infrastructure/blob/main/README.md)
- [Releases](https://github.com/risesoft-y9/Digital-Infrastructure/releases)
- [risesoft-y9/Digital-Infrastructure on GitHub](https://github.com/risesoft-y9/Digital-Infrastructure)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/risesoft-y9-digital-infrastructure