Um cenário típico para usuários do VSTS (Visual Studio Team Services, antigo Visual Studio Online) é precisar liberar acesso a usuários externos. Por exemplo, uma empresa que contrata fornecedores para desenvolvimento terceirizado de software precisa conceder acesso aos times do fornecedor que atuarão nos projetos armazenados em seu VSTS.

O VSTS permite que esse problema seja resolvido das mais diferentes maneiras, que variam de acordo com a facilidade de implementação e a conveniência no uso. Venha ver neste post como habilitar esse cenário em sua conta do VSTS.

Como comentei acima, o VSTS é extremamente flexível em termos de modelo de autenticação. Isso significa que há várias formas de resolver o acesso de usuários externos (pessoas de fora de sua empresa) à sua conta corporativa do VSTS. Neste post vou discutir algumas das abordagens possíveis:

1. Cenário básico: Usuários MSA
2. Cenário intermediário: Azure AD simples, sem SSO
3. Cenário avançado: Azure AD federado, com SSO

Para cada um desses cenários, vamos assumir a existência de duas entidades:

• O cliente: Nosso cliente é a empresa fictícia “Cliente Demo L3”. A conta de VSTS é clientedemol3.visualstudio.com e seu domínio Azure AD é o clientedemol3.onmicrosoft.com. Nosso cliente tem um usuário “admin” responsável pela administração do domínio AAD e da conta VSTS. Seu e-mail é [email protected]. Esse mesmo usuário tem uma Microsoft Account particular associada ao e-mail [email protected].
• O fornecedor: O fornecedor será a Lambda3, claro . O domínio Azure AD da Lambda3, em nosso exemplo, é o lambda3.com.br. Já o usuário da Lambda3 serei eu mesmo (Igor Abade), com o e-mail igor.abade[arroba]lambda3.com.br.

Mas afinal o que vamos ver? Quero mostrar como a empresa Cliente Demo L3 poderia dar acesso a um usuário externo – no nosso exemplo, eu – para que ele pudesse atuar em um projeto no seu VSTS clientedemol3.visualstudio.com. Como você pode imaginar, esse é um cenário bastante comum para nós, já que nossos desenvolvedores e/ou consultores ALM precisam acessar as contas VSTS de nossos clientes sempre que participamos de algum projeto.

Cenário básico: Usuários MSA

O primeiro cenário considera um cliente que, por algum motivo, escolha não utilizar um domínio Azure AD integrado ao VSTS para gerenciar as identidades de seus desenvolvedores. Esse é o cenário mais simples de todos, já que depende apenas da conta VSTS. A bem da verdade, quando o VSTS foi lançado (quando ainda se chamava VSO), esse era o único cenário possível. O suporte a AAD veio só depois.

Quando não há um diretório AAD associado a uma conta VSTS, as identidades precisam ser Contas Microsoft (“Microsoft Account” ou MSA). Significa que qualquer pessoa que queira acessar nossa conta fictícia clientedemol3.visualstudio.com precisa, primeiramente, criar uma Conta Microsoft em account.microsoft.com. Nos primórdios do VSO VSTS era assim que a gente fazia aqui na Lambda3:

• Criava uma Conta Microsoft com o e-mail da Lambda3 (neste caso, igor.abade[arroba]lambda3.com.br);
• Adicionava (“convidava”) o usuário/e-mail na conta VSTS do cliente (clientedemol3.visualstudio.com);
• Quando eu quisesse acessar a conta do cliente, faria o login com minha MSA.

Apesar de bastante simples, esse modelo tem alguns problemas:

1. Duas identidades diferentes. Apesar de eu ter uma Microsoft Account com um nome de usuário idêntico àquele que uso no domínio interno da Lambda3, eles são na verdade duas coisas distintas. Por isso eu precisava manter dois conjuntos de credenciais, gerenciando duas senhas em dois sistemas completamente diferentes. Isso nos leva ao segundo problema, que é…
2. Falta de “single sign-on”. Como são duas contas diferentes, estar autenticado no domínio da Lambda3 não bastava. Eu precisava me autenticar mais uma vez quando quisesse acessar a conta VSTS do cliente. Além disso, a conta MSA pertence a mim, não à empresa. Com isso, não é possível fazer nenhum tipo de gestão corporativa desse usuário. Coisas óbvias, como bloquear um usuário quando ele se desliga da empresa, são impossíveis quando se usa contas MSA. Por fim…
3. Identidade pessoal (não-corporativa). Como dissemos, as MSA pertencem aos indivíduos que as criaram e não às empresas. Dessa forma, não há absolutamente nenhum controle corporativo (como política de senhas ou bloqueio de contas) que possa ser feito por TI.

Obviamente esse modelo não é o ideal para uma empresa e, por isso, a Microsoft estendeu o serviço para oferecer uma solução de nível corporativo para acesso ao VSTS – a integração com o AAD.

Cenário intermediário: Azure AD simples, sem SSO

Clientes que utilizam o Azure AD integrado ao VSTS (veja como integrar os dois aqui) não dependem mais de Contas Microsoft para dar acesso à sua conta do VS Team Services. Ao invés disso, eles usam contas do seu domínio na nuvem. O benefício mais importante disso é que a gestão de identidades deixa de ser distribuída (como acontece com as Contas MSA, onde cada usuário cria e cuida da sua própria conta) e passa a ser centralizada (a criação e gestão de usuário é feita pelo administrador do domínio AAD). Aliás, muitas empresas só passaram a considerar o uso do VSTS depois do suporte a AAD por conta de sua necessidade de gerenciar identidades e acessos de maneira mais “corporativa”.

Quando o Azure AD entra na equação, tudo muda. O controle de identidades deixa de ser feito no VSTS e passa para o diretório no Azure. A primeira consequência disso é que você não tem mais a opção de continuar simplesmente adicionando Contas Microsoft ao VSTS. Todas as contas precisam, necessariamente, vir do diretório.

Essa premissa – “todas as contas devem vir do diretório” – nos deixa com duas opções:

1. Continuar usando Contas Microsoft (MSA);
2. Criar usuários locais no domínio.

Continuar usando Contas Microsoft (MSA)

“Hein?”, você deve estar se perguntando. “Mas ele não acabou de falar que não dá mais para usar contas MSA?“

Bem, o que eu disse é que não dá para “simplesmente” adicionar contas MSA. Mas com um pouco de complicação, tudo se resolve.

O que muda é que, antes de adicionar uma conta MSA ao VSTS precisamos primeiro adiciona-la ao domínio AAD. Ou seja, apenas um passo a mais e o processo continua igual ao que vimos acima.

Acesse o Portal Clássico do Azure e vá para a página de administração do seu diretório. Na aba Users iremos incluir o acesso a uma conta MSA ao domínio:

Uma vez adicionado o usuário ao AAD, agora é só ir na tela de usuários do VSTS e adicionar o usuário normalmente. Ele será listado como se fizesse parte do domínio do AAD.

Criar usuários locais no domínio

Uma opção melhor, para não precisar depender de Contas MSA, é criar contas locais no Azure AD. Assim, a responsabilidade de criar os acessos deixa de ser do desenvolvedor no fornecedor e passa a ser do cliente – que, com isso, retém controle sobre essa identidade.

Voltando ao nosso exemplo: Ao invés de eu criar uma conta MSA com meu e-mail da Lambda3, meu cliente criaria um usuário para mim ([email protected]) no domínio dele:

Para criar um usuário no Azure AD é preciso informar também seu nome amigável e seu papel:

De novo (já estamos ficando craques!): Uma vez adicionado o usuário ao AAD, agora é só ir na tela de usuários do VSTS e adicionar o usuário normalmente.

Cenário avançado: Azure AD federado, com SSO

Este é, de longe, o cenário mais legal. Aliás, este é exatamente o cenário que temos com alguns de nossos mais importantes clientes. Não só o VSTS do cliente está integrada ao Azure AD, mas ele está integrado também ao nosso Azure AD. Com isso além de todos os benefícios de segurança e gerenciamento que o Azure Active Directory oferece, temos acesso a algo bem legal: single sign-on via ADFS.

Quando usamos acesso federado no Azure AD, posso me conectar a todos os serviços AAD-backed (tais como VSTS, Office 365, Dynamics CRM, Yammer e outros) usando minhas credenciais do domínio AD interno (on-premises) da Lambda3. Com a configuração correta no browser, não preciso digitar usuário e senha para acessar qualquer desses serviços. Autenticação Integrada do Windows #ftw, baby!

O princípio básico é: estabelece-se uma relação de confiança entre os domínios AAD do cliente e do fornecedor, de modo que o administrador de usuários no domínio do cliente possa adicionar usuários que pertençam ao domínio do fornecedor.

Essa relação de confiança, porém, é diferente daquilo que administradores de rede estão acostumados a ver quando falamos de domínios AD. No Azure AD, tratamos isso de duas formas diferentes:

1. Usuário comum nos dois domínios
2. Convites Azure Active Directory B2B

Usuário comum nos dois domínios

Até bem pouco tempo atrás esta era a única forma de estabelecer uma relação de confiança entre dois domínios AAD a fim de adicionar usuários de um domínio A noutro domínio B: ambos precisariam ter um usuário comum X que fosse administrador de usuários no domínio B.

Em outras palavras: Para adicionar no diretório `clientedemol3` um usuário vindo do domínio `lambda3`, é preciso que o administrador do diretório clientedemol3 seja membro do diretório lambda3. É o ato de adicionar o admin de clientedemol3 no diretório lambda3 que estabelece a relação de confiança – apenas isso, mais nada é necessário. Dá para deduzir, entretanto, que com isso acabamos num dilema de “ovo ou galinha”, já que um diretório depende do outro. Por isso, no princípio dependemos de uma terceira entidade que seja confiável tanto para o diretório clientedemol3 quanto para o lambda3. E essa entidade é a Microsoft.

Explicando melhor: Para que nosso admin no cliente possa adicionar usuários que existem no domínio da Lambda3, é preciso:

1. Adicionar uma Conta Microsoft como Administrador de Usuários em clientedemol3;
2. Adicionar a mesma conta como Usuário em lambda3;
3. Adicionar os usuários de lambda3 no AAD de clientedemol3.

Veja o passo-a-passo ilustrado abaixo:

E só para não perdermos o hábito: Uma vez adicionado o usuário ao AAD, agora é só ir na tela de usuários do VSTS e adicionar o usuário normalmente.

Convites Azure Active Directory B2B

Se você conseguiu chegar até aqui, percebeu que permitir o acesso de usuários externos a uma conta do VSTS está longe de ser algo simples e consistente, ainda que seja algo relativamente comum e que tende a ser visto mais e mais por aí, à medida que as empresas começam a perder o medo da nuvem e levam seus workloads para lá. Ciente da importância da federação entre domínios (por todos os motivos que já vimos ao longo deste post), a Microsoft começou a investir na solução definitiva para tratar de maneira consistente essa relação de confiança entre tenants Azure AD: o Azure Active Directory B2B Collaboration.

Em poucas palavras, o Azure AD B2B é a ferramenta da Microsoft para integrar identidades entre empresas parceiras através de mecanismos simplificados de configuração e gestão. No futuro eu provavelmente farei um post a respeito. No momento, se você quiser saber mais a respeito de como o Azure AD B2B funciona, assista a este vídeo.

Nas palavras da Microsoft:

[O Azure AD B2B collaboration] simplifies management and improves security of partner access to corporate resources including SaaS apps such as Office 365, Salesforce and more, Azure Services and every mobile, cloud and on-premises claims-aware application.B2B collaboration improves security, as partners manage their own accounts and enterprises can apply security policies to partner identities access.

Azure Active Directory B2B collaboration is easy to configure with simplified signup for partners of all sizes even if they don’t have their own Azure AD via an email-verified process. It is also easy to maintain with no external directories or per partner federation configurations.

Para usar o Azure AD B2B com o VSTS, vamos usar o modelo de convites por email. A vantagem dessa abordagem, quando comparada com a anterior, é que não precisamos adicionar a Conta Microsoft do administrador do nosso cliente em nosso domínio para que ele possa convidar nossos desenvolvedores. Muito melhor, não?

Vamos começar criando os convites. Na versão de preview (atualmente o Azure AD B2B está em public preview) é preciso criar um arquivo CSV com a lista de usuários que serão convidados. O admin do cliente, partindo de um arquivo de exemplo, construiria um CSV como o abaixo para convidar os desenvolvedores da Lambda3. Ou seja, ainda que no exemplo abaixo ele esteja convidando apenas a mim, poderia ter convidado vários desenvolvedores/consultores de um vez. Mais uma vantagem do Azure AD B2B sobre o modelo de usuário comum nos dois domínios.

Com o CSV preparado, entre na opção de adicionar usuários do Portal do Azure para fazermos upload do CSV:

Depois do upload do CSV, você tem acesso a um relatório onde é possível acompanhar o processo do envio e aceite dos convites:

Cada um dos desenvolvedores recebe um e-mail com o convite. Ao aceitar, é redirecionado automaticamente para o VSTS do cliente!

Para concluir o processo: Uma vez que o convite tenha sido aceito (e, por conseguinte, o usuário tenha sido adicionado ao AAD), agora é só ir na tela de usuários do VSTS e adicionar o usuário normalmente.

Concluindo…

Este post acabou muito mais longo do que eu esperava quando comecei a escrevê-lo, mas achei que devia registrar aqui esse conhecimento que – francamente – não achei consolidado em lugar nenhum.

E você, caro leitor? Tem uma situação parecida em sua empresa? O que achou dessas dicas? Deixe seu comentário!

Um abraço,
Igor

(Cross-post de http://www.tshooter.com.br/2016/04/19/autenticando-usuarios-externos-no-vsts/)