Uma plataforma de login único que não para no servidor de identidade: entrega o portal onde o usuário vê e acessa os sistemas que pode usar, entrada por passkey (sem senha) com a credencial permanecendo no diretório LDAP ou Active Directory que você já tem, administração simples de usuários, perfis e sistemas — e um cadastro de pessoas que os seus sistemas corporativos estendem, em vez de duplicar.
Não é só incômodo do usuário: é risco de segurança, custo de suporte e uma pergunta de auditoria que ninguém consegue responder direito.
Uma senha para cada sistemaSeis sistemas, seis senhas — que na prática viram uma senha repetida em todos, ou um bilhete colado no monitor.
Quem acessa o quê vive numa planilhaMantida à mão, desatualizada, e que ninguém consegue conferir contra o que os sistemas de fato permitem hoje.
Desligamento que não revoga nadaO e-mail é bloqueado no mesmo dia; o acesso ao ERP, ao drive e ao banco continua ativo por meses.
Painel de controle preso à hospedagemA ferramenta que administra usuários e serviços é a mesma dos anos 2000, amarrada ao servidor de hospedagem e incapaz de enxergar os sistemas modernos da empresa.
Servidor de identidade que ninguém operaUma solução genérica foi instalada, ficou complexa demais para o time manter e virou mais um sistema que só uma pessoa entende.
A mesma pessoa cadastrada em cinco lugaresRH, portal, sistema acadêmico, chamados e ERP, cada um com sua versão do nome e do contato — e nenhum sabe qual está certa.
O usuário não sabe onde clicarCada sistema tem uma URL diferente, guardada nos favoritos de alguém. Gente nova leva semanas para descobrir o que existe.
O APsso não é só o servidor que emite o token. Ele entrega também as telas que a empresa realmente precisa no dia seguinte à instalação — em português, prontas para usar.
O servidor de identidade propriamente dito, falando OAuth 2.0 e OpenID Connect — os padrões que praticamente todo sistema moderno entende.
A porta de entrada do usuário: um painel que mostra só os sistemas que aquela pessoa pode acessar, com um clique para entrar em cada um.
A administração da plataforma: quais sistemas existem, quais perfis cada um tem e quem recebeu o quê — sem editar banco na mão.
O cadastro-base de pessoas da organização — e a base que os sistemas do cliente estendem com os dados do domínio deles.
Aqui o APsso deixa de ser "mais um servidor de identidade" e vira a camada onde a TI da empresa se organiza. Cada serviço abaixo já entra autenticado pelo APsso, com as permissões vindas do mesmo lugar — é a função que os painéis de controle antigos cumpriam, feita para os serviços que as empresas usam hoje.
Registra-se o sistema no Módulo de Controle, definem-se os perfis dele, e a aplicação é apontada para o APsso como provedor de identidade — o mesmo procedimento que você faria com qualquer provedor de login corporativo, porque o protocolo é padrão. A partir daí ele aparece no portal de quem tem perfil concedido, e some do portal de quem não tem. Nenhuma alteração nos sistemas que já estavam plugados.
Duas decisões que mudam a postura de segurança da empresa sem exigir nada do usuário: a entrada moderna passa a ser sem senha, e a senha que ainda existir continua guardada onde sempre esteve — no diretório corporativo, não numa base nova.
O usuário entra com a biometria ou o PIN do próprio aparelho — celular, notebook ou chave física. Nada para digitar, nada para lembrar, nada para anotar num papel.
A credencial de passkey é presa ao endereço real do seu login e nunca sai do dispositivo. Site clonado não consegue usá-la, e não há senha para o usuário entregar sem perceber.
Quando ainda houver senha, ela vive só no LDAP — a plataforma não mantém uma segunda base de senhas. A política que o diretório já aplica (expiração, complexidade, bloqueio) continua valendo, sem duplicidade.
Serve tanto um LDAP aberto quanto o Active Directory da empresa. As contas continuam onde estão e no processo que o time já conhece — o APsso entra por cima, não no lugar.
O portal é customizável: identidade visual, nome, disposição dos blocos e a nomenclatura que a sua empresa usa de verdade. O usuário não sente que está num sistema de fornecedor — sente que está no portal da instituição dele, o que é justamente o que faz a adoção acontecer sem treinamento.
Cadastrar pessoa, montar equipe, conceder perfil num sistema e revogar acesso são telas simples, em português, feitas para serem usadas por quem cuida de pessoas — não por quem entende de protocolo de identidade. A parte técnica fica com quem instalou; o dia a dia fica com você.
Este é o ponto que separa o APsso de um servidor de identidade comum. O Gestor de Equipes mantém o cadastro-base da pessoa: quem ela é, seus identificadores e seus dados essenciais. Os sistemas corporativos do cliente estendem essa base com os atributos do domínio deles — e o portal passa a conhecer o usuário por esses atributos sem precisar conhecer o sistema que os produziu.
Num portal institucional comum, o usuário que entra é apenas uma conta: o sistema sabe autenticá-lo e nada mais — não existe vínculo, e cada sistema precisa descobrir por conta própria se aquela pessoa é funcionário, docente ou aluno, normalmente integrando com o RH ou com o acadêmico. No APsso o vínculo já vem junto da identidade, porque o sistema de origem estendeu o cadastro-base. O portal sabe quem entrou e o que aquela pessoa é na organização.
Comparação honesta: o Keycloak é um excelente servidor de identidade, e não temos interesse em fingir o contrário. A diferença está no que vem junto — e em quem precisa operar o conjunto depois.
| Critério | APsso plataforma de acesso + serviços |
Keycloak servidor de identidade |
Painel legado cPanel e similares |
|---|---|---|---|
| O que é | Login único + portal do usuário + administração de acessos + catálogo de serviços | Servidor de identidade completo e maduro, para você construir o resto em volta | Painel de administração de hospedagem, com usuários e serviços do próprio servidor |
| Portal para o usuário final | Sim — mostra os sistemas que a pessoa pode acessar | Não é o objetivo: entrega telas de conta e de administração, não um portal de sistemas | Sim, mas limitado aos recursos da hospedagem |
| Permissão por sistema | Nativa e obrigatória: sem perfil concedido, o login é recusado para aquele sistema | Existe o modelo de papéis por cliente; a política de negócio é construída por você | Permissão por conta de hospedagem, não por sistema corporativo |
| Entrada sem senha (passkey) | Sim, como forma de entrada da plataforma — biometria ou PIN do próprio dispositivo | Suporta o padrão; habilitar e ajustar o fluxo é configuração do administrador | Não — usuário e senha do painel |
| Onde a senha fica | Só no diretório LDAP/AD — a plataforma não mantém uma segunda base de senhas | Pode federar com LDAP/AD ou manter base de credenciais própria, conforme a configuração | Base própria do painel |
| Portal customizável | Sim: identidade visual, blocos e nomenclatura da organização | Telas de login personalizáveis por tema; não há portal de sistemas para o usuário final | Aparência limitada ao modelo do painel |
| Cadastro de pessoas estendido pelos seus sistemas | Sim — é o diferencial: RH, acadêmico ou comercial acrescentam seus atributos e o portal passa a conhecer o vínculo | Permite atributos personalizados no usuário; o modelo de pessoas, equipes e vínculos do negócio é você quem constrói | Não se aplica |
| Serviços agregados | Banco, drive, monitoração, repositórios, cofre e sistemas próprios plugados e prontos | Nenhum — integrar cada serviço é projeto à parte | E-mail, FTP, banco e site do próprio servidor |
| Serviços modernos | Contêineres, cluster, observabilidade e ferramentas de engenharia | Agnóstico: integra com o que você configurar | Não alcança: nasceu para hospedagem tradicional |
| Esforço para operar | Baixo: a plataforma é entregue configurada e operada por quem a desenvolve | Médio a alto: exige quem conheça a ferramenta a fundo para manter e atualizar | Baixo, mas em troca de ficar preso ao modelo dele |
| Idioma e suporte | Português, com suporte falando com você direto de Bauru–SP | Comunidade internacional; suporte comercial via fornecedores | Depende do revendedor da licença |
| Padrões abertos | OAuth 2.0 e OpenID Connect — sem protocolo proprietário | OAuth 2.0, OIDC e SAML | Autenticação própria do painel |
| Onde roda | No seu ambiente ou operado por nós — decisão sua | Onde você instalar | No servidor de hospedagem que tem a licença |
| Melhor cenário | Empresa que quer acesso unificado e serviços de TI prontos sem montar um time de identidade | Organização com time próprio para desenhar e operar a camada de identidade | Quem só precisa administrar hospedagem de site e e-mail |
Se a sua empresa já tem uma equipe de identidade, precisa de SAML para sistemas antigos, exige federação com vários provedores externos ou tem requisitos de certificação muito específicos, o Keycloak provavelmente atende melhor — e nós ajudamos a implantá-lo, sem empurrar o nosso produto. O APsso é para quem quer o resultado (acesso unificado, portal e serviços funcionando) sem assumir a construção e a operação dessa camada.
Centralizar o acesso concentra risco — e é por isso que as escolhas de segurança do produto são conservadoras por padrão, não configuráveis para o lado errado.
Não basta o sistema estar cadastrado: sem perfil concedido, ninguém entra — inclusive o administrador. Esquecer de restringir deixa de ser possível.
Tirar a pessoa do cadastro central encerra o acesso a todos os sistemas plugados. Fim da caçada sistema por sistema no desligamento.
A credencial que cada sistema usa para conversar com o APsso vive no cofre de segredos e é injetada no deploy — nunca fica em arquivo de configuração versionado.
OAuth 2.0 e OpenID Connect implementados sobre base consolidada. Nada de esquema de autenticação caseiro — a parte crítica segue a especificação.
Quem concedeu qual perfil, para quem e quando fica registrado — a resposta que a auditoria pede sobre controle de acesso.
Cada módulo expõe métricas e é acompanhado pela nossa stack de observabilidade: se o login degrada, o alerta chega antes da reclamação.
Dois modelos de hospedagem e uma implantação por ondas — os sistemas vão sendo plugados um a um, sem virada de chave arriscada.
A plataforma roda na nossa infraestrutura, com atualização, backup e monitoração por nossa conta. Você usa e nós mantemos — o caminho mais rápido para começar, e o mais comum entre clientes sem time de infraestrutura.
Quando os dados de acesso precisam ficar dentro de casa, o APsso é implantado no seu cluster ou nos seus servidores, com o mesmo padrão de infraestrutura como código que usamos em tudo. A operação pode ficar com você ou conosco.
Mostramos a plataforma rodando de verdade e entendemos quais sistemas você quer unificar primeiro.
Plataforma no ar, cadastro de pessoas e equipes carregado, estrutura de sistemas e perfis desenhada com você.
Um sistema por vez entra no login único, começando pelo de menor impacto. O acesso antigo só é desligado depois que o novo funciona.
Time treinado no Módulo de Controle, rotina de concessão e revogação estabelecida, e acompanhamento contínuo.
A demonstração é feita num ambiente real, com os serviços plugados — e já dá para discutir quais dos seus sistemas entrariam primeiro.