Projetando uma permissão.
Uma permissão representa a capacidade de acessar um recurso protegido ou executar uma operação protegida. Quando você estiver implementando a sua própria classe de permissão, você deve tomar várias decisões de design de alto nível. Uma das primeiras etapas é determinar exatamente quais recursos de sua permissão personalizada é projetada para proteger.
Em seguida, você deseja decidir se há dúvidas sobre as permissões de sobreposição. Embora você deseja evitar que duas permissões que protegem o mesmo recurso, em algumas situações você não pode razoavelmente evitá-lo. Por exemplo, a permissão para acessar código não gerenciado pode abranger também outras permissões, porque o código que recebeu permissão para acessar código não gerenciado pode fazer quase tudo por meio de uma API não gerenciada. No entanto, quando não é concedida a permissão para acessar código não gerenciado, você ainda precisará conceder permissões para acessar outros recursos específicos. Portanto, faz sentido permissão acessar código não gerenciado a ser separada de outras permissões.
Como saber se uma sobreposição na cobertura de permissão é gerenciável? Há uma resposta absoluta, mas é de uma coisa pensar se uma das permissões representa mais refinado acesso do que a outra permissão para que ele normalmente mais prontamente terão que a permissão de outra. Quando este for o caso, direitos de acesso é fácil de fazer em muitos casos, que facilita a tarefa do administrador.
Depois de decidir quais recursos de sua permissão protegerá e resolveu os problemas sobre a sobreposição de permissões, você deve decidir como levemente deve ser o controle de acesso granular. A resposta a essa pergunta afeta a maneira como você projetar as variáveis que representam o estado da permissão e determina se os administradores podem configurar o acesso ao recurso protegido. Ele também pode afetar o desempenho, facilidade de uso e outros fatores.
Para ilustrar alguns desses problemas de design, considere alguns dos designs que foi escolhidos para o Classe FileIOPermission que o.NET Framework fornece. Cada opção de design afeta as variáveis que representam o estado da permissão.
Um único bit, que significa "usa todos os arquivos" ou "não usar nenhum arquivo", dependendo do seu valor.
Dois bits, que significa "ler todos os arquivos" e "gravar todos os arquivos", ou não, dependendo de seus valores.
26 bits que significa "usar todos os arquivos na unidade especificada".
Uma matriz de seqüências de caracteres, listando todos os arquivos aos quais o acesso é fornecido.
É claro que existem várias vantagens e desvantagens a serem considerados. Por exemplo, a permissão de bit único é muito simples, rápida e fácil de entender, mas ele apresenta uma seleção de tudo ou nada para os administradores, não podem ser desejáveis. Outras opções que especificam uma representação mais complexa do estado de permissão podem prejudicar o desempenho em algum grau. Você deve avaliar essas compensações e considere a possibilidade de que você não deve criar mais de uma permissão para proteger o mesmo recurso. Em geral, você deve projetar sua classe de permissão para que o estado da permissão seja tão complexo quanto necessário, sem afetar significativamente o desempenho.
Embora outros designs são possíveis, a maioria das permissões execute um dos seguintes padrões de design padrão ou uma combinação disso:
Booleanas permissões. Este tipo mais simples de objeto de permissão contém um ou mais bits, cada um dos quais corresponde a "permissão para fazer X". Você tem a permissão ou não. Um exemplo desse tipo de permissão é o classe SecurityPermission, cujo estado contém variáveis Boolean, que representa o direito de fazer coisas diferentes, como, por exemplo, permissão para chamar código não gerenciado, cada um deles é seja permitida ou não.
Níveis de permissões. Essa forma mais detalhada de permissão tem variáveis que representam cada tipo de acesso como um número de zero (indicando que nenhum acesso em todos os) para algum número mais alto (acesso irrestrito totalmente de significado), com alguns níveis entre os dois. Por exemplo, você pode usar o UIPermission classe para expressar a níveis variados de permissão para usar o windows, de nenhuma permissão de interface do usuário para permissões irrestritas de interface do usuário, com poucas gradações entre os dois.
Permissões de objeto de lista. Esse tipo de permissão fornece uma especificação muito detalhada para o que é e não é permitido. O classe FileIOPermission é um bom exemplo desse tipo de permissão, pois seu estado é representado por listas de arquivos em que determinados tipos de acesso são permitidos. Permissões de listas são mais úteis para proteger os recursos que contêm um grande número de objetos nomeados.
Em geral, é uma boa idéia para minimizar dependências externas na sua classe de permissão personalizada, porque sua permissão em cada assembly depende terão de ser carregado quando o sistema de segurança necessita de sua classe de permissão. Se possível, você deve colocar a sua permissão personalizada e as classes de atributo associadas a ele em um assembly separado, para reduzir a probabilidade de que outros assemblies será carregados desnecessariamente.