Função, herança, elevação de privilégios e alterações de senha do SharePoint
Funções, definições de função e atribuições de função
Uma função consiste em duas partes: uma definição de função e uma atribuição de função.
O nível de permissão, ou a definição de função é a lista de direitos associados à função. Um direito é uma ação pode ser controlada exclusivamente dentro de um site do SharePoint. Por exemplo, um usuário com a função Read pode procurar páginas na site e exibir itens em listas. Permissões de usuário nunca são gerenciadas usando direitos. Todas as permissões de grupo e de usuário são gerenciadas por meio de funções. Uma definição de função é um conjunto de direitos acoplado a um objeto específico. Definições de função (por exemplo, Full Control, Read, Contribute, Designou Limited Access) têm como escopo para o site e signifiquem a mesma coisa em qualquer lugar dentro do site, mas seus significados podem diferir entre sites dentro do mesmo conjunto de sites. Definições de função também podem ser herdadas do site pai, assim como as permissões podem ser herdadas.
Atribuição de função é o relacionamento entre a definição de função, os usuários e grupos e o escopo (por exemplo, um usuário pode ser um leitor na lista 1, enquanto outro usuário estiver um leitor na lista 2). A relação expressa por meio da atribuição de função é a chave para tornar o gerenciamento de segurança do SharePoint baseado em função. Todas as permissões são gerenciadas por meio de funções; Você nunca atribuir direitos diretamente a um usuário. Atribua significativos apenas conjuntos de direitos (definições de função) que são bem definidas e consistentes. Você pode gerenciar permissões exclusivas, adicionando ou removendo usuários e grupos para ou de definições de função por meio de atribuições de função.
O administrador do site pode personalizar as definições de função padrão e criar funções personalizadas adicionais usando a página Gerenciar funções, que lista as definições de função disponíveis no site.
Herança de definição de função
O SharePoint dá suporte à herdação de definições de função de forma semelhante à forma como ele dá suporte à herdamento de permissões e a quebra da herança de definição de função requer também a quebra da herança de permissões.
Cada objeto do SharePoint pode ter seu próprio conjunto de permissões ou herdam suas permissões de seu contêiner pai. O SharePoint não dá suporte à herança parcial, em que um objeto herdaria todas as permissões de seu pai e também teria algumas de suas próprias permissões. As permissões são herdadas ou exclusivas. O SharePoint não dá suporte à herança direcionada. Por exemplo, um objeto pode herdar somente de seu contêiner pai, não a partir de outro objeto ou contêiner.
Quando um site herda as definições de função, as funções são somente para leitura, como as permissões de somente leitura em um website herdada. O usuário pode navegar para o site pai que contém as definições de função exclusiva por meio de um link. A configuração padrão para todos os novos sites, inclusive os sites com permissões exclusivas, é para herdar as definições de função do site pai. Quando as permissões são exclusivas, definições de função podem ser revertidas para definições de função herdada ou editadas como definições de função local.
Herança de definição de função em um site da Web afeta a herança de permissões seguindo estas regras:
Não podem herdar permissões, a menos que ele também herda as definições de função.
Não é possível criar definições de função exclusiva, a menos que ele também cria permissões exclusivas.
Não é possível reverter às definições de função herdada, a menos que ele sairá também todas as permissões exclusivas dentro do site. As permissões existentes são dependentes as definições de função.
Não é possível reverter para permissões herdadas, a menos que ele também reverte todas as definições de função herdada. As permissões de um site sempre são vinculadas às definições de função para esse site.
Gerenciando os tokens do usuário
SharePoint busca informações de token de usuário do banco de dados do SharePoint. Se o usuário nunca visitar o site ou o token do usuário foi gerado mais de 24 horas anteriormente, SharePoint gera um novo token de usuário tentar atualizar a lista de grupos aos quais o usuário pertence.
Se a conta de usuário for uma conta NT, o SharePoint usa a interface de AuthZ para consultar o serviço de diretório do Active Directory para a propriedade TokenGroups. Isso pode falhar se o SharePoint estiver sendo executado em um modo de extranet e não tem permissão para consultar o Active Directory para essa propriedade.
Se a conta de usuário for um usuário de associação, o SharePoint consultará o ASP.NET RoleManager para todas as funções às quais o usuário pertence. Isso poderá falhar se não houver um arquivo de .config adequado para o arquivo executável atual.
Se o SharePoint não conseguir obter as associações de grupo do usuário do Active Directory ou <roleManager>, o token recém-gerado conterá apenas a ID de segurança exclusiva do usuário (SID). Nenhuma exceção é acionada, mas uma entrada é gravada no log do ULS do servidor. O novo token também é gravado no banco de dados do SharePoint para que ele não vai ser gerar dentro de 24 horas.
Depois que o SharePoint obtém um token atualizado, a partir do banco de dados do SharePoint ou gerando um novo token, SharePoint define o carimbo de hora a ser a hora atual e, em seguida, retorna para o chamador. Isso garante que o token é atualizado por 24 horas.
Depois que o objeto SPUserToken for retornado ao chamador, é responsabilidade do chamador não usar o token depois que ele expirar. Você pode escrever um utilitário auxiliar para acompanhar a expiração de token Registrando a hora quando você obter o token e comparar a comparação com a hora atual contra SPWebService.TokenTimeout .
Se um token expirado é usado para criar um site do SharePoint, uma exceção será lançada. O valor de tempo limite de token padrão é 24 horas. Ele pode ser acessado por meio de SPWebService.TokenTimeout .
Elevação de privilégio
Elevação de privilégio, um recurso que foi adicionado ao Windows SharePoint Services 3.0, permite executar programaticamente as ações no código usando um maior nível de privilégio. O método SPSecurity.RunWithElevatedPrivileges permite fornecer um delegado que executa um subconjunto de código no contexto de uma conta com privilégios mais altos do que o usuário atual.
A seguir está um uso padrão do RunWithElevatedPrivileges.
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// Do things by assuming the permission of the "system account".
});
Com frequência, para executar ações no SharePoint, você deve obter um novo objeto SPSite para efetuar as alterações. Por exemplo:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(web.Site.ID))
{
// Do things by assuming the permission of the "system account".
}
});
Embora a elevação do privilégio fornece uma técnica poderosa para gerenciar a segurança, ele deve ser usado com cuidado. Você não deve expor mecanismos de danos diretos, não controlados por pessoas com poucos privilégios ignorar as permissões concedidas a eles.
Importante: Se o método passado para RunWithElevatedPrivileges incluir quaisquer operações de gravação, a chamada para RunWithElevatedPrivileges deverá ser precedida por uma chamada para SPUtility.ValidateFormDigest() ou SPWeb.ValidateFormDigest() .
Alterações automáticas de senha
O recurso de alteração automática de senha permite atualizar e implantar senhas sem executar tarefas de atualização manual de senha em várias contas, serviços e aplicativos web. Isso torna o gerenciamento de senha no SharePoint mais simples. Você pode usar o recurso de alteração automática de senha para determinar se uma senha está prestes a expirar e redefinir a senha usando uma cadeia aleatória longa, criptograficamente forte.
Conta gerenciada
Use contas gerenciadas para implementar o recurso de alteração automática de senha. Contas gerenciadas melhorar a segurança e garantir o isolamento de aplicativo. Com as contas gerenciadas, você pode:
Configure o recurso de alteração automática de senha para implantar as senhas em todos os serviços em um farm.
Configure aplicativos web do SharePoint e serviços, que estão sendo executados em servidores de aplicativos em um farm do SharePoint, para usar contas de domínio diferente.
Mapeie contas gerenciadas para vários serviços e aplicativos Web em um farm.
Crie várias contas em Active Directory Domain Services (AD DS) e registre cada uma dessas contas no SharePoint.
Você também pode registrar contas gerenciadas e habilitar o SharePoint para controlar senhas de conta. Os usuários precisam ser notificados sobre alterações de senha planejadas e interrupções de serviço relacionadas, mas as contas usadas por um farm do SharePoint, aplicativos Web e vários serviços podem ser redefinidas e implantadas automaticamente no farm, conforme necessário, com base em agendas de redefinição de senha configuradas individualmente.
As operações que você pode usar a classe SPManagedAccount para executar incluem:
Alterar senha
Definir um agendamento de alteração de senha
Propagar alteração de senha
Descubra quando uma senha foi alterada pela última vez
Impor comprimento mínimo para senha
Para obter mais informações sobre a API da conta gerenciada, confira os seguintes links: