donovanf

Demystified Series: WinForms App Single Sign On in 2 Lines of Code!

Download this episode

Download Video

Description

Welcome to the Demystified Series where we seek to identify and present the strategic and critical pieces of information that a developer needs to get up and running, and feel confident, in building identity-aware, directory-enabled applications.

Many developers are unaware of two information rich objects available to them for role-based validation and that can also be leveraged to verify authenticated access, essentially single sign on (SSO), to their application because the user has already logged onto the desktop. These are the WindowPrincipal and WindowsIdentity objects. The purpose of this screencast is to demystify how to leverage the rich information these objects provide – starting with just 2 lines of code.

Sample code for this screencast is available here:
https://channel9.msdn.com/ShowPost.aspx?PostID=154871

For further information regarding Identity and Access Management, please visit:
http://microsoft.com/ad
http://microsoft.com/adam
http://microsoft.com/miis

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • neilhut
      Very cool:P

      What are you using behind the scenes? Is this basic AD? I am wondering how I would set this up.
    • guercheLE

      Dear,

      In Microsoft Visual Basic 2005 Express Edition, the line of code below

      System.AppDomain.CurrentDomain.SetAppDomainPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal)

      gives me the following error

      Value of type 'System.Security.Principal.PrincipalPolicy' cannot be converted to 'System.Security.Policy.PolicyLevel'.

    • donovanf

      neilhut:
      Thanks! The great thing about using the WindowsPrincipal and WindowsIdentity objects is that there is no set up required – yet these encapsulate information about Windows accounts whether the machine is domain attached or not. Therefore, simply pull in the appropriate namespace(s) and instantiate the objects required for either your single or repeated validation use. From there, if desired, the developer can interrogate the Name property to evaluate for a specific DOMAIN\ requirement for access to the application. The application could then be terminated with an error prompt based on the evaluation or possibly pop up another form to collect credentials for authentication to another identity store. Also, the Type property shows the type of authentication used to identify the user – Kerberos, NTLM, etc. There may be business reasons for the application to also make decisions based on this information.


      guercheLE:
      It appears that you need to adjust your syntax just a bit to:
      AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)

      This should fix it. Smiley

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.