Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Customizing Authentication and Authorization in WSE Using AzMan : Page 3

Web Services Enhancements (WSE) supports message-based security, policy-based administration, and has the flexibility to move message-exchange out of the HTTP-only world. But despite the combination of support for authentication and authorization for cross-platform principals there's still the question of how to deal with custom principals. AzMan can help.

Adding AzMan Runtime Access Checks
Having completed the AzMan administration tasks, you can begin implementing access checks in code. First you need to add some keys in your project's web.config file that map to the AzMan store, the appropriate Application Group, Application Name, and Operation Name as follows:

<add key="AzmanFilePath" value="msxml://C:\DAT\DATAuthorizationStore.xml"></add> <add key="ApplicationGroup" value="DATApplicationsGrp"></add> <add key="ApplicationName" value="DealerManagementApplication"></add> <add key="ActivatePostpaidCustomer" value="1"></add> <add key="AccountAdjustment" value="2"></add>

You also need to write a wrapper class for AzMan where you implement the CheckAccess method and all support methods. The class shown in Listing 2 provides an example.

In the AzMan class shown in Listing 2, the CheckAccess method authenticates a caller for a particular operation in a defined application. First you call the OpenApplication(appName) method that in turn initializes the AzMan store by calling AzManStore.Initialize(0, @azmanFPath,null) method. Next, it opens the application from the store by calling the AzManStore.OpenApplication(ApplicationName,null) method. After that you can create a client by calling the method InitializeClientContextFromStringSid(sid, 1, null). Note that the call initializes the client context from a SID (Security Identifier) and sets the second parameter to 1, which turns off checking the SID against the Windows User Store—but will still match the custom SID (Custom Principal) that you assigned to the Application Group programmatically. The constant in that call is AZ_CLIENT_CONTEXT_SKIP_GROUP and its value is set to 1 in azroles.h.

You can then pass this client context to the CCHandle.AccessCheck("tsk",Scopes,Operations,null,null,null,null,null) Azman method, which is quite handy. The AzMan COM component can be used from all COM-enabled languages, including scripting languages such as JavaScript or VBScript. Of course, that also means you often have to deal with Variant data types. The sample code uses an object[] array (which in .NET covers the Variant type) and converts that to an integer type later on.

Now take a look at the Web method that a consumer program would call. If you have an application that stores the principals in a SQL database and you have an AzMan store against which you want to run access checks, you first need to map your principals to the Custom SIDs stored in the database so that you can later retrieve those SIDs to perform operations.

When creating custom SIDs you must establish a SID design for your application. For example, you might have S-1-9-AppInstanceGUID-UserGuid, where 9 is the resource manager subauthority and AppInstanceGUID and UserGUID are each broken into four sub authorities. You can also use S-1-9-AppInstanceGuid-UserRID, where UserRID represents a unique number for the user in the scope of the application instance. For more information see the AzMan documentation.

For example: In this application S-1-9-1-AGT0001 represents the first Dealer agent.

private string GetAgentId() { string agentId = null; if (RequestSoapContext.Current != null & RequestSoapContext.Current.Security.Tokens.Count > 0) { foreach (UsernameToken tok in RequestSoapContext.Current.Security.Tokens) { agentId = tok.Username; } } else { agentId = null; } return agentId; }

The preceding code first authenticates the token sent by the caller program against the database as described earlier during the authentication portion of this article. After authentication succeeds, and the caller is authenticated then you can use the agentId to retrieve the custom SID from the database.

[WebMethod] public string AccountAdjustment(string telephoneNumber, string amount) { Azman azInstance = new Azman(); bool accessResult; string adjustedAmount = "0"; string sid = GetAgentSid(GetAgentId()); try { string operationName = "AccountAdjustment"; accessResult = azInstance.CheckAcces(operationName,sid); if(accessResult) { //Code to Adjust amount against the account of telephoneNumber adjustedAmount = amount; } else { throw new Exception("AuthorizationAccessDenied: You are not authorized to perform this operation!"); } } catch(Exception ex) { throw ex; } return adjustedAmount; }

You can add custom SIDs to either roles or Application Groups. When the application loads you can add all the custom SIDs that correspond to agent IDs to the Application Group by calling the AddSidToGroup(sid,applicationGrp) method. Later, you can check access through the AzMan API as discussed above.

So, you've seen how to perform SoapHeader authentication using a custom UserNameTokenManager and then perform authorization through AzMan by using a custom principal. By the way, the username tokens described in this article are encrypted even though I didn't discuss that aspect. You should encrypt and decrypt tokens using RSA or some other encryption algorithm or use a secure protocol such as HTTPS as Microsoft recommends.

Muhammad Naseem Siddiqui has worked for the last three years as a technical lead for Kalsoft (Pvt) Ltd, Pakistan, a software consulting and research firm focused on .NET development, consulting, and advanced .NET research. His area of expertise is SOA, XML Web services, and cross-platform integration. He has also worked for Microsoft Consulting Services for .NET development, and EAI Solutions.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date