Support catalogue restriction through nested claims

Abierto
  • ¿Algo no está bien?
#497 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
java
Área
authorization, backend-api-design

Línea de trabajo

Comienza localizando el manejo de restricciones de service-catalogue y la evaluación del root-claim de JWT en la Onyxia API. Revisa cómo se representan las configuraciones de restricciones existentes antes de elegir una estructura para los claims anidados. Done debe incluir anidamiento arbitrario, coincidencia de valores en listas anidadas, claves de mapa seguras frente a puntos y que no se rompan las configuraciones existentes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Currently access to service catalogues can only be restricted based on root claims in the JWT. In some cases it would be useful to restrict access based on some nested property in the token.

E.g. we have a custom claim:

{
  "custom": {
    "custom2": {
      "someList": [ "a", "b" ]
    }
  }
}

And would like to restrict access to a catalogue based on the presence of an item in custom.someList (this could be a list of access groups a user is in, for example).

Of course, periods are valid characters in a map key, so some thought will have to be given to how this is handled. In addition, arbitrary amounts of nesting should be supported, and it should not break existing configurations of Onyxia.. Perhaps something similar to this could work:

"restrictions": [
  {
    "userAttribute": {
      "subAttribute": ["custom", "custom2"]
      "key": "someList",
      "matches": "b"
    }
  }
]

where subAttribute is an ordered list of attributes to traverse through in the JWT. Another way could be to use some nested object,

"restrictions": [
  {
    "nestedUserAttribute": {
      "key": "custom",
      "nestedUserAttribute": {
        "key": "custom2",
        "userAttribute": {
          "key": "someList",
          "matches": "b"
        }
      }
    }
  }
]

These are of course just suggestions off the top of my head, there are probably much better ways of solving it 😀

Lenguaje dominante
Java
Estrellas
34
Forks
34
Merge medio
9 min
PR fusionados (30 d)
4

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InseeFrLab/onyxia-api

Todos los issues de InseeFrLab/onyxia-api

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.