遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/2315)
<a href="https://www.bestpractices.dev/projects/2315"><img src="https://www.bestpractices.dev/projects/2315/badge"></a>
The Sidecar Forward Proxy service is a forward proxy service with credential caching capabilities for incoming REST requests. It is one of the two applications (alongside with Sidecar Reverse Proxy service deployed as a Kubernetes sidecar to the main Primary service.
https://wiki.onap.org/display/DW/Development+Procedures+and+Policies describes requirements for acceptable contributions and is linked from the AAI project page. https://wiki.onap.org/display/DW/Java+code+style shows java code style. https://wiki.onap.org/display/DW/Developer+Best+Practices
ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA). https://wiki.onap.org/display/DW/Contribution+Agreements
https://www.linuxfoundation.org/codeofconduct
The key roles in the project and their responsibilities are described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance Current members are listed at https://wiki.onap.org/pages/viewpage.action?pageId=8226539
For AAI we have multiple committers and multiple contributors who are listed in https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ActiveandAvailableInventory All committers have access and rights to maintain the code base, approve and review incoming changes and release a new version of the artifact. This will let the project continue with minimal to no interruption if one person is incapacitated. Also this project is controlled by the Linux foundation so we can add more committers if need
The project covered in this report have more than 2 persons who actively contribute and maintain code. https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ActiveandAvailableInventory
https://wiki.onap.org/display/DW/Pre-Release+Planning+and+Notes
https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/architecture/index.html
https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/architecture/security.html
Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-develo:per/settingup/index.html AAF Specific info https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/installation/index.html https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/configuration/index.html
Documentation is updated with each release (using readthedocs.io strategy)
The badge is visible on the project's readme.io page found at https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/index.html
Most of AAF is Service Based. Colors for Management GUI were chosen by ONAP Standards for readability. Standards for Field identification are followed, for instance, "Required" are not just red, but have Asterix'
Most of AAF is Service Based, and text entered is user defined. It is, however, designed primarily for Developers/IT Professionals, so English (as instructed) is first language of logging, etc.
AAF Tool is intended to delegate User/Password to the Organization. When this is not available, however, AAF stores as salted-SHA256 Hashes. Certificate Authentication (Provided) is promoted above any use of User/Password
All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed
Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA
Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.
Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711
Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style
SONAR compile time and Static Reporting tools enforce coding styles.
Sidecar Forward Proxy is written in Java, "run everywhere" on JVM.
The application does not create native binaries. All build info generated by Maven are stored as Jenkins Outputs for Job.
Sidecar Forward Proxy deliberately and specifically has no cross dependencies for artifacts.
The application does not create native binaries. AAF jars are always generated exactly the same way, with the same results, per source code set.
Source is delivered as Java Jars. Docker Containers are also generated, for use in either Docker Directly, or within Kubernetes.
The compiled docker images and jar files can be installed/used as the user sees fit. Both run on JVM or docker. So there is no reason to selecting locations etc.
All the components require only java and maven to begin with for a developer to quickly install and test it.
Even for deployment using OOM and the right amount of resources, we can deploy the full AAI/ONAP suite in less than a day. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html
External dependencies are controlled using the pom file, which can be found in the root folder for the project https://git.onap.org/aaf/cadi/tree/sidecar/fproxy
NexusIQ sonar scan is run on all the projects on a weekly basis
External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit
We avoid depending on deprecated/obsolete functions.
Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.
When regressions occur, we add tests for them.
We use sonar to measure the code coverage. https://sonar.onap.org/about
Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies
This is documented on our wiki: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis
Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.
AAF and CADI are designed to help applications meet Secure Principles, using best available Cryptography and practices (i.e. HTTP/S, TLS 1.1+, Certificates, etc)
AAF's CADI Framework defaults usage of TLS 1.1+
Algorithms are provided by Java, which are constantly being updated. Often, a simple upgrade to a later JDK is all that is required.
AAF's CADI framework provides the ability to encrypt all passwords from Config Files, access to JKS/P12 files, etc. No clear text passwords are allowed within the configuration.
AAF/CADI defaults all clients to HTTP/S TLS1.1 & TLS1.2 from the outset.
TLS processing is handled by Java
CADI Clients do not allow HTTP... only HTTP/S, and these are defaulted to TLS 1.1+
All release artifacts are signed by the Linux Foundation prior to release.
All releases (which are tagged major/minor/patch) are signed by Linux Foundation.
AAF/CADI always requires both Authentication, and Authorization. That is actually the purpose of this software to enable Apps to also always require Authentication and Authorization in a Fine-grained manner.
The project tries to use hardening mechanism whenever possible. AAF (and CADI) log all secure transactions, with critical info, such as kind of Authentication, the ID, the IP , etc.
AAF/CADI is itself a security framework for Authentication and Authorization . What it does is all documented in the initial docs.
https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/index.html
SonarQube is run. See https://sonar.onap.org/dashboard?id=org.onap.aaf.cadi.sidecar%3Afproxy.
All the projects use Java which are memory safe that run on JVM. Also the end product runs on a docker container which is run on docker.
后退