- 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
- 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
- MFA com aplicativo autenticador (TOTP) ou código por email
Modelo de autorização
O Caradhras expressa autorização com o Casbin. 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 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.
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. O Caradhras não inicia sem
LICENSE_KEY. Defina-a com uma chave de licença global. Leia License Manager.
Para ver para que cada serviço do Access Manager usa o backend, leia Caradhras no Access Manager.
