Olá pessoal, tudo certo?
Ainda falando sobre a Enterprise Library 4.1, hoje vamos olhar o Security Application Block. Segurança de modo geral é um aspecto muito importante na arquitetura de soluções e deve ser tratado com todo cuidado.
Através do Security Application Block, podemos definir os métodos de autenticação de usuário e autorização de acesso às funcionalidades da aplicação, de acordo com os papéis (roles) definidos para cada usuário, de um modo fácil e configurável.
A partir do Hands On Labs da EntLib 4.1, temos alguns exercícios para autenticação e autorização na pasta C:\Enterprise Library 4.1 HOL\CS\Security.
Veja um exemplo de implementação no arquivo SecurityHelper.cs, abaixo:
1: using System.Security.Principal;
2: using System.Threading;
3: using System.Web.Security;
4:
5: namespace BugSmak.Security
6: {
7: class SecurityHelper
8: {
9: private SecurityHelper()
10: { }
11:
12: public static bool Authenticate(string username, string password)
13: {
14: bool authenticated = false;
15:
16: // TODO: Authenticate Credentials
17: authenticated = Membership.ValidateUser(username, password);
18:
19: // TODO: Get Roles
20: if (!authenticated)
21: return false;
22:
23: IIdentity identity;
24: identity = new GenericIdentity(username, Membership.Provider.Name);
25:
26: string[] roles = Roles.GetRolesForUser(identity.Name);
27: IPrincipal principal = new GenericPrincipal(identity, roles);
28:
29: // Place user's principal on the thread
30: Thread.CurrentPrincipal = principal;
31:
32: return authenticated;
33: }
34:
35: public static bool Authorized(string rule)
36: {
37: bool authorized = false;
38:
39: // TODO: Check rule-base authorization
40: return authorized;
41: }
42: }
43: }
A classe SecurityHelper acima implementa os métodos de Autenticação e Autorização, que podemos chamar para esses tratamentos em nossa aplicação. Como um benefício da EntLib, o modelo de programação é legível e de fácil configuração, economizando horas de projetos para a implementação desse mesmo tratamento.
Por exemplo, a partir da definição da classe SecurityHelper , podemos criar um formulário de Sign In, como vemos abaixo:
De onde chamamos a autenticação do usuário através do botão Sign In. Abaixo você tem a implementação do formulário acima, com destaque para o método btnLogin_Click(), disparado pelo click no botão Sign In:
1: using System;
2: using System.Windows.Forms;
3: using BugSmak.Security;
5: namespace BugSmak
7: public partial class LoginForm : Form
9: public LoginForm()
10: {
11: InitializeComponent();
12: }
13:
14: private void btnLogin_Click(object sender, EventArgs e)
15: {
16: string username = this.txtUsername.Text;
17: string password = this.txtPassword.Text;
19: bool authenticated;
20: authenticated = SecurityHelper.Authenticate(username, password);
21:
22: if (authenticated == true)
23: this.DialogResult = DialogResult.OK;
24: else
25: this.errorLabel.Visible = true;
26: }
27: }
28: }
Nesse caso, a autenticação é feita através da definição prévia de um arquivo de configuração de usuários e credenciais, usado pelo SecurityHelper para validação, como vemos no exemplo abaixo:
Arquivo: Users.xml
Com o código acima e usando o Security Application Block, podemos ainda autenticar nossos usuários e validar as funcionalidades liberadas de acordo com cada perfil. Por exemplo, o métoto Create() abaixo é autorizado para os papéis “Employee”, “Developer” e “Manager” de usuários autenticados, veja:
1: [PrincipalPermission(SecurityAction.Demand, Role = "Employee")]
2: [PrincipalPermission(SecurityAction.Demand, Role = "Developer")]
3: [PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
4: public static RaiseBug Create()
5: {
6: // TODO: Check Authorization
7: return new RaiseBug();
8: }
O Security Application Block ainda suporta outros métodos de autorização, como o Authorization Rule Provider, o AzMan Provider ou métodos customizados conforme a necessidade. Essa configuração é feita sobre o arquivo de configuração App.Config ou Web.Config, com a ferramenta Enterprise Library Configuration:
Usando o Authorization Rule Provider, nosso método de autorização ficaria assim:
1: public static bool Authorized(string rule)
2: {
3: bool authorized = false;
5: // TODO: Check rule-base authorization
6: // No parameter passed to GetAuthorizationProvider method as
7: // we'll set the defaultAuthorizationInstance in App.config.
8: IAuthorizationProvider ruleProvider;
9: ruleProvider = AuthorizationFactory.GetAuthorizationProvider();
10:
11: authorized = ruleProvider.Authorize(Thread.CurrentPrincipal, rule);
12:
13: return authorized;
14: }
Ao final, nosso arquivo de configuração terá uma definição semelhante a essa:
1: <?xml version="1.0" encoding="utf-8"?>
2: <configuration>
3: <configSections>
4: <section name="securityConfiguration"
5: type="Microsoft.Practices.EnterpriseLibrary.Security.Configuration.SecuritySettings, Microsoft.Practices.EnterpriseLibrary.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null" />
6: </configSections>
7: <securityConfiguration defaultAuthorizationInstance="RuleProvider"
8: defaultSecurityCacheInstance="">
9: <authorizationProviders>
10: <add name="RuleProvider"
11: type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null">
12: <rules>
13: <add name="Raise Bug" expression="R:Employee OR R:Developer OR R:Manager" />
14: <add name="Assign Bug" expression="R:Manager" />
15: <add name="Resolve Bug" expression="R:Developer OR R:Manager" />
16: </rules>
17: </add>
18: </authorizationProviders>
19: </securityConfiguration>
20: </configuration>
Em resumo, cada Application Block da EntLib permite uma fácil configuração e uma menor codificação para recursos importantes como a autorização e a autenticação que vimos neste post.
Por enquanto é só! Até o próximo post :)
Waldemir.