Skip to main content
Um usuário é uma pessoa com um login pessoal. Os usuários pertencem à organização por meio do Workspace. Os programas autônomos usam uma conta conta de serviço ou função. Os usuários pertencem a uma organização, não a uma conta. Um usuário acessa recursos de conta por meio de funções de conta atribuídas. As políticas da organização concedem permissões da organização, não acesso a recursos de conta.

Adicionar um usuário

Por que isso é sempre um convite, e o que um 201 não promete.

Grupos

Políticas organizacionais e atribuições de função de conta para uma equipe de usuários.

Removendo um usuário

O que ele separa, o que ele deixa para trás, e quando ele entra em efeito.

​
Adicionar um usuário

Abra Organization → Users e, em seguida, Invite users. Insira um ou mais Email addresses e, opcionalmente, selecione Groups. Cada endereço recebe seu próprio convite; os resultados mostram quais convites foram bem-sucedidos.Os convites pendentes são listados na página Users com uma ação Cancel invitation.
Cada pessoa escolhe sua própria permanente nome de usuário. Os convites não reservam nem substituem o nome de usuário do destinatário. email é o único campo obrigatório. groups é o mais útil: ele coloca a pessoa em seus grupos no momento em que eles se juntam, então não há nenhuma janela onde eles existem sem permissões e alguém tem que se lembrar de consertar isso.
Esta chamada sempre cria um convite, nunca um usuário. A resposta é o convite, e a pessoa se torna um usuário quando o aceita — mesmo que já tenha um login do Basaltic. Não há nenhum caminho que adicione alguém a uma organização sem o consentimento dele.Até que eles aceitem, eles são uma linha na lista de convites pendentes, não em Users.
É recusado com 409 em dois casos, que valem a pena dizer separadamente:
Um 201 significa que o convite foi criado, não que o e-mail chegou. O envio é o melhor esforço: se o e-mail falhar, o convite ainda existe e a solicitação ainda é bem-sucedida, porque perder um convite que já foi gravado seria pior.Então “eles nunca receberam o e-mail” é um estado real, e a solução é cancelar o convite pendente e adicioná-los novamente em vez de esperar.

​
Convites

Um convite registra seu convidado real. invited_by.type distingue um usuário, conta de serviço ou sessão de função assumida; os convidados de máquina também incluem a identidade da conta e não têm um endereço de e-mail humano. Um convite é a metade pendente da chamada acima. Não há um endpoint separado de “criar convite” na API pública — você adiciona um usuário e um convite é o que você recebe quando ele ainda não existe.
Os convites pendentes são listados em Organization → Users, abaixo dos usuários, com Cancel invitation em cada linha. Quando não houver nenhum, a seção diz “Nenhum convite pendente”.
Cancelar um convite não é o mesmo que remover um usuário: ele retira uma oferta que ninguém aceitou. remove em vez disso.

​
Grupos

Um grupo coleta os principais e detém políticas. Anexar uma política a um grupo em vez de a cada membro é a diferença entre uma alteração e n alterações quando as permissões da equipe são movidas.
Abra Organization → Groups e escolha Create Group. Insira um Name e uma Description opcional.As guias Users e Policies do grupo gerenciam seus membros de usuário e anexos de política da organização.
Os grupos contêm apenas usuários e não são aninhados. As contas e funções de serviço usam anexos de política de conta e de política organizacional separados. As permissões da organização de um usuário incluem políticas anexadas diretamente e por meio de seus grupos. Uma atribuição de função de conta a um grupo permite que seus membros solicitem essa função; sua política de confiabilidade ainda deve aceitar cada usuário assumindo.

​
Onde anexar uma política

Anexe políticas da organização a grupos quando a concessão descrever uma equipe ou trabalho. Use anexos diretos do usuário para exceções individuais. As permissões de conta pertencem a funções e contas de serviço, não a usuários ou grupos. As políticas em linha são uma terceira opção e uma mais restrita — veja managed and inline policies.

​
Removendo um usuário

Abra o usuário, escolha Settings e, em seguida, Remove user na zona de perigo. Digite o valor de confirmação exibido antes de confirmar.
A remoção de um usuário o remove de esta organização. Ele não exclui o login do Basaltic, que pode pertencer a outras organizações, e não exclui nada que eles criaram — os recursos pertencem à conta, não à pessoa que os criou. A remoção é atômica e leva toda a sua pegada nessa organização com ela: associações de grupo, anexos de política, políticas inline, seu limite de permissão e, finalmente, a própria associação.
Isso significa que re-adicionar o mesmo e-mail mais tarde produz um usuário com sem permissões — nada disso volta. Se você estiver removendo alguém temporariamente, anote em quais grupos eles estavam primeiro: nada mais faz isso.
A remoção encerra a associação a esta organização. Revise as sessões de função do usuário como parte do desligamento; as páginas de sessão de STS da conta mostram o principal de origem e permitem revogação explícita.

​
Permissões

Essas APIs usam https://workspace.basaltic.sh. Suas ações estão no namespace workspace: e devem ser concedidas através de políticas da organização. Consulte Permissões de espaço de trabalho para obter informações sobre as verificações de recursos e as ações de atribuição de função de conta.

​
Próximo

Contas e funções de serviço

As identidades que não são pessoas.

Escrever políticas

O que vai no documento que você anexar aqui.