Welcome to MSDN Blogs Sign in | Join | Help

Microsoft Code Name “Zermatt” developer framework beta

For those that have been writing claims-aware web applications for AD FS, you have a leg up on the value the claims-based model brings to application development. You’ve already taken the step to architect your applications for cross-organization, cross-security boundary, cross-platform access. Now, with Microsoft’s recent release of the “Zermatt” beta, this claims-based model is set to enable a new generation of business applications that fully participate in the Identity Metasystem (Kim Cameron’s blog). With Zermatt you can build “Relying Party” (think “resource-side” in AD FS terms) applications, custom “Identity Providers” (think “account-side” in AD FS terms) and security token services (STS). It also provides the means to issue managed information cards (think Windows CardSpace on the Microsoft platform) to users and consume those information cards on relying party sites. Exciting stuff! That said, Zermatt in of itself is not the next version of AD FS, but it is a developer framework that enables building claims-aware applications and security token services on the Microsoft platform.

Zermatt, as a developer framework, not only supports the WS-Federation passive requestor (browser client) case as used in AD FS, but it also supports the long awaited for “active requestor” (think web services) case. So whether you’re writing an ASP.NET application or a client application that employs web services, Zermatt exposes a single object model for you to use for accessing identity and claims. The beta comes with a broad collection of sample applications categorized to demonstrate basic, intermediate and advanced scenarios. So there’s something for everyone. To help scope your investigation/discovery, here’s some suggestions. 

Get Zermatt here. On the download site is a white paper by Keith Brown that is a must read and will set you up for working the sample applications.

For ongoing insights into building various application scenarios with Zermatt, follow Vittorio’s blog, Vibro.NET. Start from his Zermatt announcement and work your way forward, chronologically.  Also, for those that would like an all-up understanding on the broader need for digital identities in today’s application access paradigm, I highly recommend his book, “Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities”.

Lastly, if you don’t want to install beta bits onto your machine, here are some links to downloadable resources:

  • Download Virtual PC: here.
  • Windows Server 2008 Trial: here.

Enjoy!

Posted by donovanf | 0 Comments
Filed under: , ,

Active Directory Federation Services (ADFS) for ASP.NET 2.0 Developers

This post is to inform you of a couple new screencasts on Channel9 hosted by Keith Brown. In these, Keith drills into the role AD FS can play in helping you architect/develop claims-based Web applications which offer their Internet users not only a Web SSO experience, but supports user access by federation partners as well. Both are much needed in today’s Web applications!

For some time now developers have built Web applications around a domain or application-based identity infrastructures to provide user access to their applications. In the domain-based Windows environment, Windows integrated authentication has worked its magic on the user’s behalf by extending their single, interactive authentication event to a host of applications and services providing the user with a single signon (SSO) experience. But, this has one catch, a domain-based identity infrastructure retains absolute authority over the identities within its domain and let’s no others in. It creates users and services and makes all the trust decisions for them within its borders, that is, within the firewall. However, as the business need for ubiquitous user access has evolved, the demand upon Web applications is to no longer only support users inside the firewall. Potentially, these same applications, or portions of them, need to now be accessed by vendors, partners or customers as well. How do you provide access for these users to applications built around the domain-based identity model? At the minimum, it infers additional user account management. Each one must have a domain-based identity inside the firewall. If this means hundreds or potentially thousands of additional user accounts, it’s a further burden on IT and helpdesk staff to manage password resets and provisioning/de-provisioning of accounts for those loosely affiliated with the organization.

Federation:

Active Directory Federation Services (AD FS), in Windows Server 2003 R2 and 2008, enables the cross-domain reach of your Web applications while preserving a Windows Integrated Authentication experience inside the firewall and providing a SSO experience across Web applications for those outside the firewall. Furthermore, AD FS makes additional user account management unnecessary because it provides an infrastructure for establishment of federation trust relationships with partner organizations. Due to the federation trust relationship, accounts from the partner’s domain can be trusted to have access to specific applications within your domain. Therefore, in a federated trust model, each organization continues to manage its own domain-based identities, but they can also securely project and accept these digital identities, including their associated access rights, into or from other partner organizations.

So what are the advantages of moving to this cross-domain, federation trust model for identities? First, from a SSO perspective, AD FS manages this for your AD FS enabled Web applications. AD FS maintains SSO for any Web application relying on it to broker authentication events via the pre-established federation trust relationships. After the user’s initial authentication, if they navigate to other AD FS enabled Web applications that are under the same federation trust, the user experiences SSO with these applications as well. Secondly, from an architect’s and developer’s perspective, with AD FS in the mix, you can design and build your applications with the intent that they may be accessed by anyone. Essentially, write the application once, but fully anticipate its use by users from multiple security domains – again, some from inside the firewall and others from outside. And, because AD FS is based on the open standard WS-Federation protocol, it can also broker access to your application from any non-Microsoft platform that implements WS-Federation. This further extends the reach of your federation-aware application.

The next logical question is, if you decouple the authentication event from the application, how does the application get the information it needs to make its access control decisions? As mentioned above, the cross-domain digital identities also can contain access rights, asserted in the form of claims that the application can consume. The application can use these claim values to enforce its internal access control decisions. A very handy technology for mapping access rights to roles is Windows Authorization Manager (AzMan). I’ve already discussed AzMan in previous blogs, but its role-based access control (RBAC) capabilities can be employed in the claims-based programming model that AD FS uses. Hence, the purpose of this blog. To introduce you to the Channel9 screencast series focusing on claims-based programming with AD FS, hosted by Keith Brown. Please follow the links below.

Enjoy!

Channel9 Screencasts:

Active Directory Federation Services (AD FS) Part 1 by Keith Brown
Active Directory Federation Services (AD FS) Part 2 by Keith Brown

Posted by donovanf | 2 Comments
Filed under: , , , ,

.NET Programming with System.DirectoryServices.AccountManagement (SDS.AM)

To fill out the trio of my System.DirectoryServices resource postings, I wanted to point you to an excellent MSDN Magazine article, "Look it Up: Managing Directory Security Principals in the .NET Framework 3.5," to learn about the System.DirectoryServices.AccountManagement namespace which is available in the .NET Framework 3.5. To whet your appetite, the authors, Joe Kaplan and Ethan Wilansky, state:

"This new namespace has three primary goals: to simplify principal management operations across the three directory platforms [Active Directory Domain Services (AD DS), Active Directory Lightweight Directory Services (AD LDS, formerly named ADAM) and the local Security Account Manager (SAM)], to make principal management operations consistent regardless of the underlying directory, and to provide reliable results for these operations so you are not required to know each and every one of the caveats and special cases.

By waiting a few years for the .NET landscape to gel, Microsoft has actually outdone its previous work in ADSI by providing an even better API for these features that takes advantage of .NET capabilities while also providing much better support for new directory platforms such as AD LDS."

Whereas SDS.P is for the pedal-to-metal LDAP developer and SDS.AD is for managing Active Directory components, SDS.AM is for the developer that needs to work with security principals, creating user accounts and groups, managing group memberships, simplified searching and more - this namespace is for you. A code sample accompanies the article so you can get right to work.

Other resource links:

Namespace overview
Programming with groups

Enjoy!

Posted by donovanf | 1 Comments
Filed under: , ,

AzMan in Windows Vista? You bet! And “Longhorn” too!

The fourth screencast in the AzMan series by Keith Brown is now available on Channel9. It is titled, “AzMan on Windows Server Code Name “Longhorn” and Windows Vista.” Yes, developers can continue to take advantage of a new featured AzMan on these next generation client and server platforms. The AzMan product group did a significant amount of work to bring you the following new features:

  • Support added for Microsoft SQL Server to also be a store for AzMan’s policy.
  • Support for business rule groups, that is, groups whose membership is determined at run-time by a script.
  • Support for custom object pickers, so that application administrators can use the AzMan MMC Snap-in for applications that use Active Directory Lightweight Directory Services (AD LDS, formerly named ADAM) or SQL user accounts.
  • Improvements were made to the API to simplify the programmer's need to perform commonly used queries and access checks.
  • LDAP queries no longer are limited to only user objects.
  • Additional events are recorded in the log if auditing is active.
  • Significant efficiencies were targeted and gained in this version of AzMan in relationship to loading the store, access check time and store creation time.

If you want to see the new AzMan in action, go to your Windows Vista machine, choose Run… and type azman.msc. Click on the Help icon in the Microsoft Management Console (MMC) for documentation on the above mentioned features. Keith highlights several of these enhancements in the screencast. For more resources on AzMan, please refer to my blog post "Windows Authorization Manager (AzMan): The Best Kept Secret...

Enjoy!

Posted by donovanf | 1 Comments
Filed under: , , ,

.NET Programming with System.DirectoryServices.Protocols (SDS.P)

In line with Ethan Wilansky’s previous white paper on System.DirectoryServices.ActiveDirectory (SDS.AD), I am pleased to announce his second white paper available on MSDN that highlights the .NET 2.0 System.DirectoryServices.Protocols (SDS.P) namespace. Also, as mentioned in my previous SDS.AD blog post, with the advent of SDS.AD and SDS.P in .NET 2.0, directory services programming for the managed code programmer has come of age. These rich programming APIs bring to the .NET platform the ability to manage a directory that previously was only available through Active Directory Services Interface (ADSI) scripting, C++ or the LDAP API. This white paper exposes some of the richness of the SDS.P programming model and its capabilities.

Staying true to the Directory Services namespaces design principles, SDS.P introduces a low barrier to entry and self documenting object model as well. SDS.P programmers will again see that they can learn the API quickly. The design goals for SDS.P were to target high performance, cover 100% of the scenarios and be easy to use. The object model is connection based with a request and response object. SDS.P is for server-side directory developers who seek the maximum control and power over the directory. SDS.P supports advanced directory operations like fast concurrent bind, certificate based authentication, transport layer security and much more. So don’t hesitate – read this exceptional paper and try out the sample code download.

Following are the scenarios exposed in the sample code:  Enjoy!

  • Common management tasks
    CreateUsers server_or_domain_name targetOu numUsers
    AddObject server_or_domain_name dn dirClassType
    AddAttribute server_or_domain_name dn attributeName attributeValue
    AddAttribute2 server_or_domain_name dn attributeName attributeValue
    AddAttributeUri server_or_domain_name dn attributeName attributeUriValue
    AddMVAttribStrings server_or_domain_name dn attribName "attribVal1,...attribValN"
    DeleteAttribute server_or_domain_name dn attributeName
    EnableAccount server_or_domain_name dn
    DeleteObject server_or_domain_name dn
    MoveRenameObject server_or_domain_name originalDn newParentDn objectName
  • Search operations
    SimpleSearch server_or_domain_name startingDn
    AttributeSearch server_or_domain_name startingDn "attribName1,...attribNameN"
    TokenGroupsSearch server_or_domain_name DnofUserAccount
    PagedSearch server_or_domain_name startingDn numbericPageSize
    AsyncSearch server_or_domain_name startingDn
    Asq server_or_domain_name groupDn
    Vlv server_or_domain_name startingDn maxNumberOfEntries nameToSearch
  • Advanced authentication operations
    Sslbind fullyQualifiedHostName:sslPort userName password
    FastConBind server_or_domain_name user1 pword1 user2 pword2 domainName
    Tls fullyQualifiedHostName_or_domainName userName password domainName
    cert fullyQualifiedHostName:sslPort clientCert certPassword
Posted by donovanf | 0 Comments
Filed under: , ,

Windows Authorization Manager (AzMan): The Best Kept Secret…

I don’t know how many times I’ve had someone say to me that has “discovered” AzMan that they feel it is one of the best kept secrets in Windows. However, since keeping it a secret has never been in the mind of the product team, it’s time to extend its press. Authorization Manager is a technology that essentially lets the application developer remove the hard-coded authorization policy from their application and “externalize” it in a form where it can be managed by an administrator. AzMan provides a tool for managing Role-Based Access Control (RBAC) policy in the form of a MMC Snap-in. This policy can be stored in an XML file or either Active Directory or Active Directory Application Mode. Using its API in your application, you then instantiate an AzMan context, bring in the policy and perform access checks at runtime for the various authorization decisions your application needs to make. The API can also be used for you to build your own custom management tools that may better fit with your application’s deployment needs or look-and-feel.

But, rather than drilling too deeply into things here, I’m going to use this as a jumping off point for “all things AzMan.” As with any technology there’s the potential for information saturation and then possibly ending up with less information than you needed. So although I can’t/won’t mention every resource, I’ll try and bubble up for architects and developers some of the key resources to get you going and you can dig deeper from there.

To get the ball rolling, I’m announcing here a new "Demystified Series" of screencasts on Channel9 for AzMan by Keith Brown. These should get you charged up and rolling on its concepts and programming techniques. Keith says that AzMan is, “…a hidden gem in Windows that can help you build Role-Based Access Control into your applications.” I hope you find this true as well.

Channel9 Screencasts:
    Getting Started with AzMan – Keith Brown
    Programming AzMan – Keith Brown (Code Sample)
    AzMan in the Enterprise – Keith Brown (Code Sample)

Case Studies:
     ADAM and AzMan:
           FileHold uses AzMan and ADAM in their product, FileHold '06 and '07.

     AzMan:
           Israeli National Court System 
           Lighthouse International

Technical Material:
      Overviews: 
           AzMan overview by Keith Brown   
           ”The .NET Developer’s Guide to Identity” the Authorization section of Keith’s MSDN article 

      Drill-downs:
           "RBAC for Multi-tier Applications Using Authorization Manager" by Dave McPherson   
           "Developing Applications Using Windows Authorization Manager" a most comprehensive AzMan dev resource.

Blogs:
           AzMan Team Blog don't be without it!

 Added additional screencast links - 03/08/07

Posted by donovanf | 1 Comments
Filed under: , , ,

.NET Programming with System.DirectoryServices.ActiveDirectory (SDS.AD)

I am so pleased to announce a new white paper on MSDN by Ethan Wilansky that provides an introduction to the .NET 2.0 System.DirectoryServices.ActiveDirectory (SDS.AD) namespace. With the advent SDS.AD and System.DirectoryServices.Protocols (SDS.P) in .NET 2.0, directory services programming for the managed code programmer has come of age. These rich programming APIs bring to the .NET platform the ability to manage a directory that previously was only available through Active Directory Services Interface (ADSI) scripting, C++ or the LDAP API. If by chance you have not yet read the book A .NET Developer’s Guide to Directory Services Programming by Joe Kaplan and Ryan Dunn, I highly recommend it to you. It definitively covers System.DirectoryServices (SDS) and programming using the DirectoryEntry and DirectorySearcher object model. Although Joe and Ryan touch on SDS.AD and SDS.P at various points in the book, their focus primarily was on SDS. Therefore, Ethan’s papers are an excellent complement to their book.

By way of introduction, one of the design principles for the Directory Services namespaces was to introduce a low barrier to entry and self documenting object model. The intent is that programmers can learn the APIs quickly due to their strong typing, easy navigation between types, sensible defaults, simple initialization, convenient overloads and simple and straightforward entry points. The design goals were to solve specialized problems by simplifying the process of common directory services tasks, such as: topology management, schema management, replication management and trust management.

This paper of Ethan’s focuses on SDS.AD, SDS.P is in publishing now and I'll anounce it as soon as it comes available on MSDN. As mentioned, the SDS.AD namespace’s object model is built around Active Directory service tasks and includes such concepts as forest, domain, site, subnet, partition and schema. Ethan’s paper provides both a description and practical guidance on how to begin programming with SDS. AD for some common scenarios. A code sample accompanies the paper and can be downloaded here. Once you download and unzip the file, open the DirectoryServices.ActiveDirectory solution in VS 2005. If you intend to exercise all the functionality for Active Directory you will need to create a test environment, possibly in a VPC. To execute the Console against an ADAM instance (see my blog, Step 1: Get ADAM installed) you will need to open the ADAMData class, find localhost and change it to the full machine name of the computer the ADAM instance is located on and the port of that instance. For example:       
 Change This Line of Code From:
      static string adamConnectionString = "localhost:50000"; 
 To:
      static string adamConnectionString = "your_machine_name:your_port_number";

Now, build the console application, start a Command Prompt, cd to the bin directory and run DS.AD. Executed without any parameters the application will give you a list of its available commands. This coupled with the white paper should give you a great start with SDS.AD. Following are the scenarios exposed in the sample code:  Enjoy!

• Forest, domain, and ADAM reporting tasks
GetDomainData
GetForestData
GetGcData
GetDcData
GetSchemaData
GetSchemaClassData className
GetSchemaPropertyData propertyName
GetAdamPartitions

• Schema reporting and management tasks
GetAdamSchemaData
GetAdamSchemaClassData
GetAdamSchemaPropertyData
AddSchemaClasstoAdam
AddSchemaAttributetoAdam

• Topology reporting and management tasks
GetTopologyData forestName
CreateAdSite newSiteName
CreateAdamSite targetName newSiteName
CreateSubnet newSubnet siteName
CreateSiteLink siteName newLinkName
AddSiteToSiteLink siteName siteLinkName
RemoveSiteFromSiteLink siteName siteLinkName
MoveDcToSite sourceDC targetSite
DeleteAdSite siteName
DeleteAdamSite targetName siteName
DeleteLink linkName

• Replication reporting and management tasks
GetReplicationStateData
ReplicateFromSource partitionDN sourceServer targetServer
ReplicateFromNeighbors targetServer partitionDN
SyncAllServers partitionDN
CreateNewConnection sourceServer targetServer connectionName
SetReplicationConnection server connectionName
DeleteReplicationConnection server connectionName

• Trust reporting and management tasks
GetCurrentForestTrusts
GetCurrentDomainTrusts
GetTrustWithTargetForest
GetTrustWithTargetDomain
CreateCrossForestTrust targetForest userNameTargetForest password
SetForestTrustAttributes targetForestName
ChangeForestTrustToOutbound targetForestName userNameTargetForest password
AddExcludedDomain targetForestName targetDomainName
DisableDomainNetbiosName targetForestName targetDomainName
RepairTrust targetForestName userNameTargetForest password
RemoveForestTrust targetForestName userNameTargetForest password
RemoveDomainTrust targetDomainName userNameTargetDomain password

 

Posted by donovanf | 2 Comments
Filed under: , ,

Using ADAM with ActiveDirectoryMembershipProvider for Forms Authentication

I’m going to take a bit of a detour from discussion of the specific content of Keith Brown’s paper and look at how to set up authentication using Active Directory Application Mode (ADAM) with the ActiveDirectoryMembershipProvider. Much has been written about using the SQL and AD membership providers and some regarding the use of ADAM as the identity store. So my intent here is not to re-write what is already available, but more to stitch together some of these excellent resources (create a blog mashup if you will) and add a few things around this content that further extends the developer experience with ADAM. For those that may not know, Active Directory Application Mode is Microsoft’s standalone lightweight directory service that is on par with Active Directory’s reliability, scalability, replication capability and performance ability. Therefore, it can serve well as a high performance LDAP identity store for distributed applications. With its ease of schema extensibility, it can readily serve as the repository for personalization data in Web portal and other scenarios as well.

Step 1: Get ADAM Installed
That said, let’s get after it. First you will need to get the ADAM install. If you are doing this exercise on Windows XP (SP1 or later) or Windows Server 2003, you can get the ADAM download here. For Windows Server 2003 R2, ADAM can be installed through Add/Remove Programs, Windows Components. The ADAM Step-by-Step Guide is located here. The Step-by-Step Guide is a full-bodied reference for getting up and running, but it’s overkill for our needs. Therefore, for a quick setup guide for our purposes follow steps 1 and 2 only on Erlend Oftedal’s post, Making ADAM work with ASP.NET 2.0 on Windows XP. You will notice in step 2.14 that he shows how to configure ADAM to not require a secure connection for setting passwords. Follow these instructions. It makes it more convenient for testing only but should not be used for production environments. You can refer to his post Using SSL with ADAM at a later time if you would like to set it up. Go ahead and setup ADAM. Generally, you can spin up an ADAM installation in 10 minutes or less, but it may take a bit longer if you are working through it for the first time. 

Step 2: Understand the Context
Like I mentioned, I do not want to reproduce content here but you must have a solid basis for what we’re going to do with ADAM. Therefore, to provide context the How To: Use Forms Authentication with Active Directory in ASP.NET 2.0 by Patterns & Practices serves as the model for this exercise. So, read through this document for background prior to doing the hands-on below. We will borrow from it and follow its basic pattern, but will tweak the implementation just a bit for ADAM.

Step 3: Hands-on, Create a Web Application
1. Fire up VS 2005 and create a new ASP.NET Web site called FormsAuthADAM.
2. To help us down the road, create two new folders. In the Solution Explorer, Right-click on the ...\FormsAuthADAM\ Website, choose New Folder and name it Authenticated. Repeat this step and name the new folder NonAuthenticated.
3. Drag-and-drop the Default.aspx file into the Authenticated folder.
4. Add a new Web form in the Authenticated folder called Login.aspx.
5. Add a login control to Login.aspx and set the DisplayRememberMe property to False.
6. Add a new Web form in the NonAuthenticated folder called CreateUser.aspx.
7. Add a CreateUserWizard control to CreateUser.aspx.
8. Browse the ContinueDestinationPageUrl property and select Authenticated/Login.aspx. Also set the CancelPageDestinationUrl to the same. In either case, this will send the user back to the login page.
9. Now, to complete the navigation for the Login control on the Login.aspx page. Click the Login control and set the CreateUserText property to “Create New User”.
10. Browse the CreateUserUrl property and select NonAuthenticated\CreateUser.aspx. Browse DestinationPageUrl and select Authenticated\Default.aspx.
11. Right-click on the ...\FormsAuthADAM\ Website and select Property Pages. Click on “Start Options”, Select “Specific page:” and Browse to Authenticate\Default.aspx.


Step 4: Configure the Web Application to use ADAM (the basics)
1. In the Solution Explorer, right-click on the ...\FormsAuthADAM\ Website. Select Add New Item…, Web Configuration File.
2. In the web.config file replace this line”
        <authentication mode="Windows" />
with
  <authentication mode="Forms">
   <forms
       loginUrl="authenticated/Login.aspx"    name="FormsAuthADAMCookie"
       timeout="10" />
  </authentication>


3. In the web.config file immediately following </system.web>, add the following two <location> elements to provide path-level authorization to the Web pages.

  <location path="authenticated">
    <system.web>
      <authorization>
        <deny users="?"/>
        <allow users="*"/>
      </authorization>
    </system.web>
  </location>

  <location path="nonauthenticated">
    <system.web>
      <authorization>
        <allow users="?"/>
      </authorization>
    </system.web>
  </location>


Step 5: Configure ASP.NET for ADAM Membership (the basics)
1. In the web.config file, replace
 <connectionStrings/>
with
  <connectionStrings>
    <add name="ADAMConnectionString" connectionString="LDAP://localhost:50000/OU=Users,O=TestDirectory" />
  </connectionStrings>


2. Add the following <membership> element immediately following </authentication>.

<membership defaultProvider="MyADAMMembershipProvider">
<providers>
<add name="MyADAMMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADAMConnectionString" connectionUsername="CN=ADAMAdmin,OU=Users,O=TestDirectory" connectionPassword="myADAMAdminPassword" connectionProtection="None" enableSearchMethods="true"/>
</providers>
</membership>

3. Lastly, we need to have something to display on the Default.aspx page once an authenticated user reaches it. Here we will borrow the code from the Patterns and Practices article mentioned above. Go to the Design View of the Default.aspx page and double-click on the design surface. Once in the View Code window, paste the following code inside the Page_Load event.

  Response.Write("Hello, " + Server.HtmlEncode(User.Identity.Name));
  FormsIdentity id = (FormsIdentity)User.Identity;
  FormsAuthenticationTicket ticket = id.Ticket;
  Response.Write("<p/>TicketName: " + ticket.Name );
  Response.Write("<br/>Cookie Path: " + ticket.CookiePath);
  Response.Write("<br/>Ticket Expiration: " + 
                  ticket.Expiration.ToString());
  Response.Write("<br/>Expired: " + ticket.Expired.ToString());
  Response.Write("<br/>Persistent: " + ticket.IsPersistent.ToString());
  Response.Write("<br/>IssueDate: " + ticket.IssueDate.ToString());
  Response.Write("<br/>UserData: " + ticket.UserData);
  Response.Write("<br/>Version: " + ticket.Version.ToString());

4. Now, compile and run the application. If prompted to configure the application for debugging, click yes. Once the Logon page loads, click the Create User link. On the CreateUser page, enter a new User Name, Password, fake email address and click the Create User button. Click Continue on the confirmation page to proceed to the login page. Login using the credentials of your newly created user. Create more users at will.

That’s it!! This gets you up and running using ADAM as the highly scalable identity store for your Web application(s). In my next blog I'll continue this mashup approach, but we'll continue to build on this "single, concept unifying" application. I will take you through the more advanced steps of adding attributes to your ADAM’s schema so you can store a user’s question and answer to enable password resets, etc. But this should certainly get you rolling for now!

Posted by donovanf | 1 Comments
Filed under: ,

Capitalize on the Platform’s Identity Infrastructure for Single Signon (SSO)

Providing SSO across desktop applications is certainly a desired goal in application development, but many developers think it is either not achievable, too difficult to implement, or lean on third-party solutions to provide this capability. In Keith Brown’s paper, The .NET Developer’s Guide to Identity, he  states, “There are companies that spend fortunes trying to implement SSO across the myriad of applications they've developed or purchased over the years. What I'm here to tell you is that you can get this feature for free; all you have to do is agree to write less code and instead rely on the platform to do the heavy lifting.” He also discusses in some detail the nuts-and-bolts of authentication that developers should be aware of, but his guidance is to let the platform infrastructure carry that load. Developers should simply tap into what the authentication event makes available to them through the WindowsIdentity and WindowsPrincipal classes. Keith discusses these two classes in the paper so I will not elaborate here, but my intent is to show a bit of code and point you to a couple resources so you can experiment with this on your own.

Essentially, a developer can leverage the desktop’s login for their application in just a couple lines of code. You can see in this screenshot, http://blogs.msdn.com/photos/donovanf/images/874326/original.aspx, some of the information available in each of the instantiated objects.

So how does one tap into this? First, the developer must pull in a couple namespaces, System.Security.Principal and System.Threading. Then if your application needs to do repeated access for role-based validation (such as for .IsInRole checks), it is more efficient to simply drive off the WindowsPrincipal object because there is no need to repeatedly instantiate the WindowsIdentity object. These two lines of code will accomplish this:

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);           
WindowsPrincipal myPrincipal = (WindowsPrincipal)Thread.CurrentPrincipal;

If you need the additional information that the identity object provides, you can instantiate a WindowsIdentity object and then use it to subsequently instantiate a corresponding WindowsPrincipal object. This is shown in the following two lines of code:

WindowsIdentity myIdentity = WindowsIdentity.GetCurrent();
WindowsPrincipal myPrincipal = new WindowsPrincipal(myIdentity);

Now, does leveraging the platform’s authentication absolve the application from doing its own due diligence? Most likely not. Therefore, the application could interrogate the DOMAIN provided in the .Name property or use any of the other data values provided in the objects to assess whether or not to let the application continue. Or by the presence or absence of specific data values, it could make the determination to pop-up a login window that could collect and validate credentials against AD, ADAM or another LDAP store for that matter. My point here is to simply take tactical advantage of what you can from the platform and then extend it as needed. A short seven-minute screencast presenting a coding example for this is found here on Channel9 http://channel9.msdn.com/Showpost.aspx?postid=154885. And the companion, downloadable code sample is available here http://channel9.msdn.com/ShowPost.aspx?PostID=154871. Lastly, the code example shows how to use .IsInRole with a WindowsPrincipal object to validate if the user is in any one of the WindowsBuiltInRoles. It also shows how to use the .Groups of a WindowsIdentity object to list all the group security identifiers (SIDs) to which the logged on user belongs.

Posted by donovanf | 0 Comments
Filed under: ,

A Developer’s Resource for Identity and Access (IdA) Understanding

If you were to read the following line of code in a program, what meaning might you derive from it?

grokIdA = Developer.GetIdAUnderstanding(information)

So what do I mean by grokIdA? If Grok is an unfamiliar word to you, it means to understand in a deep way. Since understanding is essentially a function of adequate and appropriately applied information, the purpose of this blog is to facilitate the types of information necessary for developers to attain a deep(er) understanding of the challenges surrounding Identity and Access (IdA). And further, to see how to apply technologies like Active Directory (AD), Active Directory Application Mode (ADAM), Active Directory Federation Services (ADFS) and Authorization Manager (AzMan) to help mitigate these challenges. The Microsoft Identity Integration Server (MIIS) product enables life-cycle management of identities (provisioning/de-provisioning and much, much more), but IdA Management (IdAM) will not be the initial focus of this blog.

Today enterprises face ever pressing regulatory compliance and audit requirements making it essential for them to solve their identity and access issues. However, I realize it can be a daunting task for a developer to research all the capabilities of the available technologies, search and find all the information available, and then stitch together an approach for building their application. Some readers may have just been assigned the task to get a handle on their enterprise’s or product suite’s IdA issues. Some may be in the research phase but are getting bogged down with information overload. And others may be well on their way to designing approaches and solutions. In any case, the premise I am working from is that this is a “journey toward understanding” which assumes that many will be traveling alongside who may be new to IdA and its problem space.  Therefore, let’s start the journey/conversation with, “The .NET Developer’s Guide to Identity” on MSDN by Keith Brown. This is an excellent document that lays out the landscape for identity from authentication to authorization to federation and much more. Enjoy.

Posted by donovanf | 0 Comments
Filed under: , , , ,
 
Page view tracker