Admins may want to be able to control which configuration claims are published on .well-known/openid-configuration. This feature would enable a configuration whitelist to filter which claims are published.

Environment :
OS: Ubuntu 20.04

If one follows sequence of commands as given in development.md, then command given below to load test data returns an error:
python3 setup.py -t -n

Error:

KeyError: 'config_api_scopes_list'

when attempted the same command second time:

shutil.Error: Destination path '/opt/jans/jans-cli/cli' already exists

setup.log and setup_error.log are attached.
setup.log
setup_error.log

Documentation for Janssen components needs to be put together.
Also, few documentation articles are scattered in individual component repos and they need to be brought together.

Benefit: Having documentation for each Janssen component is reduce learning curve for contributors and having it under one repository will make it easy to locate and update.

Due: 30th June 2021

Triage all static code analysis issues reported on Codacy
After triage, all issues that we agree to fix, should be made into project issue on appropriate Github repo.
Simpler issues should be marked 'good first issue'. This also aligns with 'CII best practices`

Benefit: Improves product stability

Due: 30th June 2021

'community' repo under JanssenProject and 'home/community' folder seem to have the same purpose. While 'community' repo only holds license, we can move that to 'home/community' and remove 'community' repo.

Benefit: All community related documentation would consolidate under 'home/community'.

Due: 31st May 2021

Hi, welcome to the Linux Foundation!

Would some folks from the Janssen project be willing to present & talk with the Open Source Security Foundation (OpenSSF) Digital Identity Attestation Working Group (WG)?

We just met December 9. We're scheduled for December 23 but I think that will be cancelled. Our next meeting (after that) is January 6, 2021, at noon Eastern Time. I think it'd be good to talk; I suspect there are many ways we could work together. At the least, we'd like to hear a summary about what you're doing.

You can see the WG notes.

Create feature roadmap for Janssen. Example : https://github.com/orgs/Unleash/projects/5

In order to ensure that Janssen continues to be high-quality and stable software, we need to ensure that code is delivered by the community confirms to high-quality code standards. Put in place dashboard/metrics that are attached to CI-CD pipeline to enforce the same.

Code quality metrics:

• Build failures
• Code coverage
• Static code quality level
• Number of issue re-opens

Due: 31st July 2021

Currently we have a way to configure scopes and claims for Userinfo and it works great. In order to flag which of those claims should also be included in the JWT Access Token today we must use an interception_script which adds all userclaims in access token. An example of such script where we add user role in access token can be found here: https://raw.githubusercontent.com/GluuFederation/gluu-gateway-setup/version_4.2.0/gg-demo/introspection_script.py

JanssenProject Enhanvement Request - Can we explore some automated way to add claims to the access token? For example to flag the subset of scope claims that, when Issued as JWT, should also end up in access token?

The current setup instructions for Janssen needs updates:

• 'oxauth' needs to be replaced by 'jans' at many places
• Most of the steps need to be removed as they have been taken care by install.py and setup.py
• Steps mentioned in 'Prepare for tests run' can not be followed as is. They need more detailing or corrections. Same steps are marked as TODO in setup.py

Benefit: All contributing developers should be able to must run all unit tests to ensure their code is not breaking any functionality. Developer workspace to enable this should be easy to setup. A step-by-step guide will help us achieve this.

Due: 31st May 2021

After running the install script (Cloud native) on a clean Ubuntu 20.04 install:

Unable to connect to the server: http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug=""namespace exists
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config
Error: Kubernetes cluster unreachable: Get "https://192.168.60.16:16443/version?timeout=32s": dial tcp 192.168.60.16:16443: connect: connection refused      Please get ip of the instance and run helm install jans -f ./jans-cloud-native/helm/values.yaml ./jans-cloud-native/helm -n jans --set global.lbIp=<ip>

I get a 404 when accessing the machine via it's IP addess and a 503 when using it's hostname.

Currently code coverage is being reported only on few Janssen repositories via Codecov or Codacy.

Need to add code coverage for repositories where it is applicable.

Benefit: This is an important quality metric which tells us how robust our automated unit and integration testing frameworks are.

Due: 31st May 2021

Owners as mentioned by Mike here
and how to and process around it here

Hello,

What is the status of this project? Is it ready for production?

Thanks!

After installing Janssen, developers who want to contribute to Janssen will want to setup working usecases end-to-end to see things in action.
We need to write guides or small tools, like oxd Spring app, that can help them see end-to-end flow. This can also help developers test their fixes before submitting PR.

Benefit: This will help prospective users quickly understand how easy it is to deploy and configure Janssen for scenarios that are relevant to them. Also, this will help reduce learning curve for new contributors.

Due: 31st July 2021

Research and consider renew refresh token on each use vs. single refresh token with multiple uses..

Due: 31st May 2021

In order to ensure that Janssen community is healthy in current state and is growing in right direction, we need to track some of these data points and frequently ask few relevant questions to community ( may be by running a survey ).

Put together a dashboard/tools via which this data can be obtained and analysed.

Data points for community health :

• Github repository : stars, forks, watch count
• Active contributors from other organisations
• Active contributors from individual capacity
• Contribution focus area : where is most of the contribution happening? Is it evenly spread? Is it where it is most needed?
• Activity levels of community on various channels
• Amount of content produced by community (blogs, videos, articles etc)

Process effectiveness:

• How long a PR has to wait before approval?
• How frequently issues are triaged?
• Contributor to committer ratio

I tried to download the clean.sh to uninstall Janssen VM but it is not found (Please see attached image

).

Janssen labels are here. Take falco labels as reference and see if there is anything that we may want for Janssen.

Collect-triage-address all warnings we currently may have.
These warnings may be getting reported in logs at different stages:

• Build
• Deploy
• Runtime

To be maximally strict with warnings, we need to ensure that we are using appropriate flags so that warnings are not suppressed. This also aligns with CII best practices.

Benefit: This will improve overall stability of software

Due: 30th June 2021

Based on comments from Mike:

Right now developers tend to ship the code and tests, and forget the rest. When developers deliver, I want to make sure we have

• code
• tests
• docs
• config-api endpoint / params (if necessary)
• mockup of what a UI would look like to configure the feature.

As mentioned by Mike here, that Sam is overall owner but there is no set process around documentation

In order to ensure that community is not facing any process bottlenecks in working on Janssen project, put together dashboard that tracks following data points:

• How long a PR has to wait before approval?
• How frequently issues are triaged?
• Contributor to committer ratio

Due: 31st July 2021

https://github.com/JanssenProject/jans-auth-server/runs/3145300978?check_suite_focus=true

Consider refresh tokens for X days and new issued refresh tokens will always keep that fixed TTL as exp. date vs. moving TTL window, where each refresh token allows an extra X days from token issuance...

I'm running the quickstart project with microk8s to have a first contact with the tool.

The project is apparently running correctly, however, I can't access the service.
There is a comment in the README stating the following:

This will install docker, microk8s, helm and Janssen with the default settings the can be found inside values.yaml. Please map the ip of the instance running ubuntu to demoexample.jans.io and then access the endpoints at your browser such in the example in the table below.

Could you describe better what mapping needs to be done? I did not understand for sure what is necessary to do to access the server.

Here is the list of all services running on microk8s:

this url on the quckstart instructions
https://raw.githubusercontent.com/JanssenProject/jans-cloud-native/master/automation/startdemo.sh && chmod u+x startdemo.sh && ./startdemo.sh

gets a 404

how and where to aggregate all issues across janssen so that community members can easily see where the contribution is needed

We want to imbibe best practices suggested by CII group in Janssen and possibly achieve badge for the same.

This issue is to create a gap analysis and a list of corresponding TODOs in order to fill the gap.

Admins may want to be able to control which configuration claims are published on .well-known/openid-configuration. This feature would enable a configuration whitelist to filter which claims are published.