- Organizações, a fronteira que é dona de todos os outros objetos.
- Usuários, as pessoas que fazem login.
- Grupos e papéis, as duas formas de reunir sujeitos.
- Permissões, que juntam um recurso a uma ação.
- Aplicações, os clientes OAuth que os chamadores máquina a máquina usam.
- Certificados, o material de chaves por trás das assinaturas de token.
Protocolos
O Caradhras aceita estes protocolos e métodos de autenticação:
- OAuth 2.0 e OIDC
- SAML 2.0
- CAS
- SCIM 2.0 para provisionamento de usuários
- LDAP: autentica usuários contra um diretório externo. O Caradhras não roda um diretório.
- WebAuthn e passkeys
- TOTP e MFA
Modelo de autorização
O Caradhras expressa autorização com o Casbin, que aceita os modelos ACL, RBAC e ABAC. Uma permissão nomeia um recurso e uma ação. O Access Manager avalia esse par contra o sujeito no token antes de um handler de produto rodar. Os sujeitos se aninham. Um grupo pode pertencer a um grupo pai. Um papel pode incluir outros papéis.
Seu provedor de identidade
Seu provedor de identidade se conecta ao Caradhras como provedor upstream por OAuth 2.0 e OIDC, SAML 2.0 ou LDAP. Provedores OIDC incluem Google, Microsoft Entra ID, Okta ou um provedor OIDC próprio. Seu provedor não substitui o Caradhras. Seus usuários então se autenticam no seu provedor. O Access Manager continua lendo os dados de identidade deles no Caradhras, e continua decidindo o que eles podem alcançar. O Access Manager não se conecta diretamente a APIs arbitrárias de provedores de identidade.
Como ele é entregue
O Caradhras faz parte do deploy do Access Manager. Você não o instala como um produto separado. O Helm chart do Access Manager faz o deploy do Caradhras como backend de identidade, e os serviços Auth e Identity o chamam. O Caradhras persiste seus dados de identidade no banco PostgreSQL que você configura para o Access Manager. Para ver para que cada serviço do Access Manager usa o backend, leia Caradhras no Access Manager.

