• Configure Generic ESB Receive Port – BizTalk

     

    one of the great capabilities provided by the ESB is the ability to create a very scalable yet dynamic receive port , this port can be as generic to accept any XML message without the need to pass the itinerary , in other words we can  create a web method that can accept any XML message as input parameter for the web method which is subscribed to your ESB engine.

    This can be done using BizTalk Web Services Publishing wizard BTSWebSvcWiz.exe , this post will walk you through the steps to create a Generic ESB Receive port:

    1. Browse to the publishing wizard,  C:\Program Files (x86)\Microsoft BizTalk Server 2010\BTSWebSvcWiz.exe

     

          2.   In this step we will create a web service using  “publish XML schema as a web Service” option

    clip_image001

     

    3.  now we need to define the Request schema type (input schema) for the web method to accept any schema type , to do this configure the receive port to use (Microfsoft.Xlang.XmlBase) by selecting “Select schema type”

    clip_image002

    now in order to be able to pickup any schema type you need to browse and pick up the BaseTypes.dll from : C:\Program Files (x76)\Microsoft BizTalk Server 2010 and pick the Microsoft.XLANGs.BaseTypes.dll

    clip_image003

    4.  Publish the port under IIS and place it under the desired web application 

    5.  Now go to BizTalk and configure the port to subscribe to a particular Itinerary as displayed :

    clip_image004

    clip_image005

    Note : it can be any resolver like (BRE) for instance.  BRE:\\policy=PolicyName

  • Internet Facing SharePoint 2010 Site with Windows Live ID – Part 6

    Logging Out Of the Website

    When the user logs in to the site using Windows Live authentication, he is effectively logging in into all Windows Live powered site, examples are Hotmail, SkyDrive…etc.

    When logging out of the website, the decision becomes if the user should be logged out from the portal only, or from Windows Live as well.


    Logging out from Windows Live

    To log out from the portal and from Windows Live completely, the user should be redirected to the Windows Live logout URL.

    The logout URL is as follows

    Staging Windows Live URL: http://login.live-int.com/logout.srf?id={siteid}&lru={siteurl}

    Production Windows Live URL: http://login.live.com/logout.srf?id={siteid}&lru={siteurl}

    {siteid} and {siteurl} should be replaced with the Site ID and Site Url respectively.

    The Site ID can be found in the Microsoft Services Manager website.

    image 

  • Internet Facing SharePoint 2010 Site with Windows Live ID – Part 5

    Registration

    A public facing website can have services and content that it wants to make available only to users that are authenticated. In this case the user is requested to register on the website and provide some information before given access to the secure content.

    When using Windows Live authentication, there are two ways that the registration can be accomplished.

    1. Ask the user for a valid Windows Live ID

    2. Create a new Windows Live ID for the user, which he will use to login to the website.

    The later could be that you want to provide an email using your own custom domain for your website’s users. In both cases, the PUID of the user should be retrieved and saved along with the rest of the user’s information.

    In both cases, the Windows Live Admin Center SDK can be used to either create a new Windows Live account and/or retrieve the user’s PUID.

    The Windows Live Admin Center SDK can be downloaded from here.

    After you retrieve the PUID of the user from Windows Live, you can save it in a custom database along with the rest of information that the user has supplied during the registration process.

    In part 4 of this series, we saw how we can use claims augmentation to add claims to the claims returned from Windows Live. During this process you have a chance to validate the PUID of the logged in user with the database of registered users you have, and then either allowing or denying access accordingly. As mentioned before, this can be achieved by defining a user policy on the web application.

  • Internet Facing SharePoint 2010 Site with Windows Live ID – Part 4

    Creating a Custom Claims Provider

    When Windows Live is used as the authentication provider, anyone with a Windows Live ID can login to the website. This could be any Windows Live domain (Hotmail, live, etc..) or a custom domain hosted on Windows Live.

    The claims that are returned from Windows live does not provide any way to identify a specific user. One useful peace of information that is provided by Windows Live is the PUID of each user. This information can be used to identify users and either deny or allow access to the website. But to be able to identify the user using the PUID, you need to have this information before the user attempts to login to the website. Usually this happens during registration, which will be discussed in a future post.

    During the registration process, information would be collection from the user and saved in a custom database along with the user’s PUID, either by asking for his Windows Live ID or by creating a new Windows live ID for the user on his behalf.

    A custom claims provider can be created to augment the claims that are returned by Windows Live. In the claims provider, the PUID of the user can be obtained and then checked in the custom database. If a user with this PUID exists, then information about this user can be saved in custom claims for later use in the website (for example, displaying a welcome note for the user). If the PUID of the user attempting to login is not found, then another custom claim can be added which then will be used to deny access to the user to the website.

    A sample implementation could be as follows

    protected override void FillClaimsForEntity(Uri context, SPClaim entity, List<SPClaim> claims)
    
    {
    
        SPClaimProviderManager cpm = SPClaimProviderManager.Local;
    
        SPClaim curUser = SPClaimProviderManager.DecodeUserIdentifierClaim(entity);
    
        SPOriginalIssuerType loginType = SPOriginalIssuers.GetIssuerType(curUser.OriginalIssuer);
    
        if (loginType == SPOriginalIssuerType.Windows)
    
        {
    
            claims.Add(CreateClaim("http://schema.WindowsLive.com/logintype", "Windows", WindowsLiveClaimValueType));
    
        }
    
        else if ((loginType == SPOriginalIssuerType.TrustedProvider) || (loginType == SPOriginalIssuerType.ClaimProvider))
    
        {
    
            string value = entity.Value; 
    
            string puid = value;
    
            //these are some business logic classes that are responsible for managing user data/
    
            UserManagement.UserManagement m = new UserManagement.UserManagement();
    
            User obj = m.GetUserByPUID(puid);
    
            if (obj == null)
    
            {
    
                //this claim will be used to deny access to users who are not registered in WindowsLive database
    
                claims.Add(CreateClaim("http://schema.WindowsLive.jo/authorized", "anuthorized", WindowsLiveClaimValueType));
    
               
    
            }
    
            else
    
            {
    
                //this claim will be used to cache the user's name
    
                claims.Add(CreateClaim("http://schema.WindowsLive.jo/logintype", "Live", WindowsLiveClaimValueType));
    
                claims.Add(CreateClaim("http://schema.WindowsLive.jo/FirstName", obj.FirstName, WindowsLiveClaimValueType));
    
                claims.Add(CreateClaim("http://schema.WindowsLive.jo/LastName", obj.LastName, WindowsLiveClaimValueType));
    
            }
    
        }
    
    }

    In this method you will have a chance to do some business logic to check if the logged in user is already registered on your website or not. Accordingly you can add a claim which you can use later to deny access to the user by specifying a user policy that denies access to any user that has a specific claim value.

    A more complete sample can be found here.

    Deploying the claims provider requires creating a feature receiver that inherits from SPClaimProviderFeatureReceiver class. An implementation can be found here.

  • Internet Facing SharePoint 2010 Site with Windows Live ID – Part 3

    Sharing Cookie between HTTP and HTTPS

    In this part of the series, I’m going to cover how to allow SharePoint to use the same authentication cookie over HTTP and HTTPS.

    When Windows Live authentication is used, the user is redirect to a Windows Live login page. After the user enters his email and password, Windows Live will validate the login information, and if the information is valid, the user is redirected back to our site.

    Windows Live requires that the redirect URL use a secure connection. After Windows Live redirects back to SharePoint, SharePoint will create the authentication cookie which will be used to authenticate the future requests until the cookie expires.

    When SharePoint creates the authentication ticket, it marks it as a secure cookie, which means any non-secure requests needs to be re-authenticated. If after the user logs in, he tries to browse the site using a non secure connection, he will be logged out and redirected back to the login page.

    To overcome this problem, a custom cookie handler has to be created.

    The code of the custom cookie hander can be found below

      class WindowsLiveChunkedCookieHandler : Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler
    
        {
    
            private ChunkedCookieHandler m_CookieHandler;
    
            public WindowsLiveChunkedCookieHandler()
    
                : base()
    
            {
    
                this.m_CookieHandler = new ChunkedCookieHandler();
    
                this.m_CookieHandler.Path = "/";
    
            }
    
            public WindowsLiveChunkedCookieHandler(int chunkSize)
    
                : base(chunkSize)
    
            {
    
                this.m_CookieHandler = new ChunkedCookieHandler(chunkSize);
    
                this.m_CookieHandler.Path = "/";
    
            }
    
            protected override void DeleteCore(string name, string path, string domain, HttpContext context)
    
            {
    
                base.DeleteCore(name, path, domain, context);
    
            }
    
            protected override byte[] ReadCore(string name, HttpContext context)
    
            {
    
                return base.ReadCore(name, context);
    
            }
    
            protected override void WriteCore(byte[] value, string name, string path, string domain, DateTime expirationTime, bool secure, bool httpOnly, System.Web.HttpContext context)
    
            {
    
                secure = false;
    
                if (context == null)
    
                {
    
                    throw new ArgumentNullException("context");
    
                }
    
                if (context.Request == null)
    
                {
    
                    throw new ArgumentException(null, "context");
    
                }
    
                if (null == context.Request.Url)
    
                {
    
                    throw new ArgumentException(null, "context");
    
                }
    
                if (!string.Equals(path, "/", StringComparison.OrdinalIgnoreCase))
    
                {
    
                    path = "/";
    
                }
    
                this.m_CookieHandler.Write(value, name, path, domain, expirationTime, secure, httpOnly, context);
    
            }
    
        }

     

    The below configuration can be used to register the custom cookie handler

    <cookieHandler mode="Custom" path="/" requireSsl="false" > 
    
              <!-- <customCookieHandler type="Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> -->
    
                    <customCookieHandler type="WindowsLive.Registration.SharePoint.WindowsLiveChunkedCookieHandler, WindowsLive.Registration.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=77a7309d51d4bf85" />
    
    </cookieHandler>