Search

Locations of visitors to this page

Categories

On this page

Using Request Headers for Metadata Address
PrincipalPermission Authorization in WF 4
Article on AD FS 2.0

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 50
This Year: 6
This Month: 1
This Week: 1
Comments: 69

Sign In

 Thursday, January 14, 2010
Thursday, January 14, 2010 7:44:42 PM (GMT Standard Time, UTC+00:00) ( )

WCF by default adds the listen address of the endpoints in the WSDL so in a scenario where the private address of the server is different from the public address you get incorrect endpoint address in WSDL.

For example if a service is listening on http://localhost:7721/ and you access its metadata using a virtual IP http://102.212.0.117/?wsdl, you get following:

Now this behavior might not work in certain scenarios and you want the metadata generation to dynamically pick the address from the request headers, similar to ASMX web services.

UseRequestHeadersForMetadataAddressBehavior enables exactly this. This opt-in behavior sets the address of endpoints dynamically, based on the request header.  

Like all other WCF behaviors, this behavior can be enabled either in the code or config.

sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());

<system.serviceModel>

  <behaviors>

    <serviceBehaviors>

      <behavior>

        <useRequestHeadersForMetadataAddress/>

      </behavior>

    </serviceBehaviors>

  </behaviors>

</system.serviceModel>

This behavior is added in .NET 4.0 and there is a QFE available for 3.5 SP1: http://support.microsoft.com/kb/971842

Comments [2] | | # 
 Tuesday, January 12, 2010
Tuesday, January 12, 2010 6:28:19 PM (GMT Standard Time, UTC+00:00) ( WF4 )

In last post, I have shown you how to get hold of OperationContext when using messaging activities. Once you got hold of OperationContext, you can use it to perform many useful tasks and one of them is Authorization. Let’s start by defining a Scope activity to hook our IReceiveMessageCallback implementation.

 

    [Designer(typeof(PrincipalPermissionScopeDesigner))]

    public class PrincipalPermissionScope : NativeActivity

    {

        public InArgument<string> PrincipalPermissionName { get; set; }

        public InArgument<string> PrincipalPermissionRole { get; set; }

 

        public Activity Body { get; set; }

 

        protected override void Execute(NativeActivityContext context)

        {

            var name = this.PrincipalPermissionName.Get(context);

            var role = this.PrincipalPermissionRole.Get(context);

 

            var principalPermission = new PrincipalPermission(name, role);

            context.Properties.Add("AuthorizationManager",

                new AuthorizationManager(principalPermission));

 

            context.ScheduleActivity(this.Body);

        }

            }

As part of Scope activity execution, I have added my ReceiveMessageCallback in execution properties collection. This enables our callback to be called for every message received by any activity inside the Scope. Once we have access to OperationContext (which is the only as the only parameter of the callback) we can use it to perform authorization.

 

        [DataContract]

        class AuthorizationManager : IReceiveMessageCallback

        {

            [DataMember]

            PrincipalPermission principalPermission;

 

            public AuthorizationManager(PrincipalPermission principalPermission)

            {

                this.principalPermission = principalPermission;

            }

 

            public void OnReceiveMessage(

                System.ServiceModel.OperationContext operationContext,

                ExecutionProperties activityExecutionProperties)

            {

                var currentPrincipal = Thread.CurrentPrincipal;

                var isPrincipalSet = false;

                var targetPrincipal = GetPrincipal(operationContext);

                try

                {

                    if (targetPrincipal != null)

                    {

                        Thread.CurrentPrincipal = targetPrincipal;

                        isPrincipalSet = true;

 

                        principalPermission.Demand();

                    }

 

                }

                catch (SecurityException)

                {

                    throw SecurityUtility.CreateAccessDeniedFaultException();

                }

                finally

                {

                    if (isPrincipalSet)

                        Thread.CurrentPrincipal = currentPrincipal;

 

                }

 

            }

And with a customer designer, this is how it look like

Comments [2] | | # 
 Sunday, December 13, 2009
Sunday, December 13, 2009 12:28:51 PM (GMT Standard Time, UTC+00:00) ( Article )

My article on AD FS 2.0 was published in November issue of MSDN magazine. Here is the URL.

http://msdn.microsoft.com/en-us/magazine/ee335705.aspx

Comments [0] | | #