Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

Criando o design de uma permissão

Uma permissão representa a capacidade de acessar um recurso protegido ou executar uma operação segura. Quando você estiver implementando sua própria classe de permissão, você precisa tomar várias decisões de design de alto nível. Uma das primeiras etapas é determinar exatamente quais recursos a permissão personalizada é criada proteger.

Você deseja em seguida para decidir se houver interesse sobre permissões sobrepostas. Embora você desejar evitar ter duas permissões que sombreiam o mesmo recurso em algumas situações, você não pode evitá-las bastante. Por exemplo, a permissão para código não gerenciado de acesso também pode abranger outras permissões, como o código que é concedida a permissão para código não gerenciado de acesso pode fazer praticamente qualquer coisa com a API não gerenciado. No entanto, quando permissão para acessar o código não gerenciado não é concedida, você ainda precisa conceder permissões para acessar outros recursos específicos. Consequentemente, faz sentido para que a permissão para acessar o código não gerenciado para ser separado de outras permissões.

Como você sabe se uma sobreposição na cobertura de permissão é gerenciável? Não há nenhuma resposta absoluta, mas uma coisa a pensar em aproximadamente se uma das permissões representa um acesso mais refinado do que a outra permissão de modo que normalmente se conceda mais prontamente do que a outra permissão. Nesse caso, a concessão dos direitos de acesso é fácil de fazer em muitos casos, o que facilita a tarefa de administrador.

Depois de decidir qual recurso a permissão protegerá e terá resolvido todos os problemas sobre a sobreposição de permissões, você precisa decidir como finas o controle de acesso refinado deve ser. A resposta a essa pergunta afeta o modo como você cria variáveis que representam o estado de permissão e determina se os administradores podem configurar o acesso ao recurso protegido. Também pode afetar o desempenho, a facilidade de uso, e os outros fatores.

Para ilustrar alguns desses problemas de design, considere alguns dos designs que podem ter sido escolhidas para Classe de FileIOPermission que fornece o .NET Framework. Cada opção de design afeta as variáveis que representam o estado da permissão.

  • Um único bit que significa “usem todos os arquivos” ou “não use nenhum arquivo”, dependendo do valor.

  • Significar de dois bits “ler todos os arquivos” e “grava todos os arquivos”, ou não, dependendo dos seus valores.

  • 26 bits que significa o uso “todos os arquivos na unidade especificada”.

  • Uma matriz de cadeias de caracteres que lista todos os arquivos ao qual o acesso será determinado.

Claramente, há várias desvantagens da considerar. Por exemplo, a permissão de único bit é muito simples, rápida e fácil de entender, mas apresenta uma opção tudo ou nada para administradores, que não podem ser desejáveis. Outras opções que especificam uma representação mais complexa do estado da permissão podem reduzir o desempenho até certo ponto. Você deve analisar essa possibilidade, e considerar que não crie mais de uma permissão proteger o mesmo recurso. Em geral, você deve criar sua classe de permissão para que o estado de permissão é como o complexo conforme necessário, sem afetar consideravelmente o desempenho.

Embora outros designs são possíveis, a maioria das permissões seguem um dos seguintes padrões de design padrão ou uma combinação disso:

  • Permissões boolianos. Esse tipo o mais simples do objeto de permissão mantém um ou vários bits, cada qual corresponde à permissão fazer “X”. Ou você tem a permissão ou não fizer isso. Um exemplo desse tipo de permissão é Classe de SecurityPermission, cujo estado contém as variáveis booleanas que representam o direito de fazer coisas diferentes, como a permissão no chamar código não gerenciado, que é permitido ou não.

  • Níveis de permissões. Esse formulário mais detalhado de permissão tem as variáveis que representam cada tipo de acesso como um número de zero (não significa nenhum acesso de todos) para qualquer número mais alto (o que significa totalmente acesso ilimitado), com alguns níveis entre os dois. Por exemplo, você pode usar Classe de UIPermission para expressar vários níveis de permissão para usar o windows, de nenhuma permissão de interface do usuário a permissão ilimitada da interface do usuário, com uma gradação entre os dois.

  • Permissões de lista do objeto. Esse tipo de permissão fornece uma especificação muito detalhada do que é e não é permitido. Classe de FileIOPermission é um exemplo desse tipo de permissão como seu estado é representado por listas de arquivos em que certos tipos de acesso são permitidos. As permissões com listas são as mais úteis para proteger os recursos que contêm um número grande de objetos nomeados.

Em geral, é uma boa ideia minimizar dependências externos em sua classe personalizada de permissão para cada assembly que a permissão depende precisará ser carregado quando o sistema de segurança da sua classe precisa de permissão. Se possível, você deve colocar sua permissão personalizado e qualquer atribui as classes associadas a ela em um assembly separado, para reduzir a probabilidade de outros assemblies serão carregados desnecessariamente.

Contribuições da comunidade

Mostrar: