Una de las cosas que la gente hace con frecuencia con Stormpath es asignar políticas de autorización (como XACML o 'permisos' de cadenas sin formato, o datos de propiedad, lo que sea) a Cuentas o Grupos almacenándolos en customData .
Los recursos primarios en Stormpath ( Account , Group , Directory , Application , Tenant ) le permiten almacenar datos sin espacio ad hoc en el recurso customData del recurso para cualquier cosa que necesite, como campos personalizados o, por supuesto, información de la política de autorización.
Por ejemplo, con Account s, sería fácil autenticar primero Account , y luego de una autenticación exitosa, obtener customData de esa cuenta y obtener su política de autorización (por ejemplo, XACML) y luego verificarla. deseo.
Esto se vuelve más poderoso cuando haces lo mismo con Group resources también.
Por ejemplo, un esquema común para encontrar una política efectiva (agregada) de una Cuenta es agregar todas las políticas en todos los Group s de los que Account es miembro. En este esquema, la cuenta está autorizada para hacer cualquier cosa que esté representada en su customData directo o en cualquiera de sus grupos customData .
No sé qué lenguaje de programación usa, pero, como ejemplo de cómo se podría lograr esto, los usuarios de Stormpath que usan Apache Shiro haga esta técnica exacta con los permisos de Shiro, el concepto integrado de la política de autorización basada en cadenas de Shiro.
Independientemente del formato de la política de autorización o del lenguaje de programación (por ejemplo, XACML en lugar de cadenas de permisos), puede aprovechar los recursos Stormpath y sus datos personalizados para esquemas de autorización similares o personalizados. Espero que eso ayude!