SharePoint Claims Based Authentication Architectures Explained Part 3 SharePoint As A Browser Based Application

WIF, short for Microsoft Windows Identity Foundation, is a set of .net frameworks that allow for the creation of claimed aware applications. It gives the user the logic that is needed in order to successfully complete any WS-Federation requests. This is the protocol that builds onto others to offer the trust and security. That is why you are allowed to request a security token when you are using an application that is browser based.

With such a scenario, it appears that the claims in WIF are similar to authentication. When a user is going to sign in, the WIF redirects them to the logon page. Once the user has been authenticated then they will be taken back to the application automatically. You may see a page called Login.aspx but that could be nothing more than an empty page. This is there for those users that need to use a smart card for authentication.

All issuers will be configured to use a method that is natural and that is secure for them to sign in. A simple username and password is usually good enough. However, there are ways for Windows to cover the needs of employers that want a more secure method to be in place. Here are some examples to make that process easily understood.

wa = wsingin 1.0 wa is for action and it will tell you if you are logging in with the wisignin1.0 or if you are logging off with wsingout1.0.

wtreatlm = http://sharepointsecurity.com/SecureCenter/ – wtreatlm is for target realm. There is a Uniform Resource Indicator that is able to identify this application. The URI is used to identify the application that the user has logged into. It also allows other tasks to be done that are associated with the claims for the application as well as replying to addresses.

Once the issuer has authenticated who the user is, it gathers those claims that are necessary for the application with the wtrealm identifying what the target application is. All of this is offered with the security token and there is a privacy key. The application can encrypt the tokens too and then the public key ahs to be used to authenticate them.

The issuer will be told which application they are using so that the claims issued will only be for that particular application to operate. The issuer will ask the browser to take them back to the application. This will send the token to that application for the claims to be processed. After this is done, the user will have access to that given application.

Some of this process may sound familiar to you. This is due to the fact that the forms authentication uses a very similar technique inside of the return URL parameter. This is done when the issuer returns to the HTML page of the browser. This creates the

with the encoded tokens inside of it.

The action of the form is going to submit the toke to the URL that is configured for that application. The user won’t see this form because the issuer has JavaScript in place to post it. Should those scripts be disabled though the user will have to click a button in order to be able to post the response to the server.

For the user there is a Windows authentication in place. The user will click on the link in the application and then the browser will be redirected in a matter of seconds right back to the application. The user will login at that point. Should the issuer require more information from the user such as a username and password or the use of a smartcard it will be done at that time. From the users point of view this type of logon process is always the same no matter what they are accessing and that is what they are after.

Share

Developing A Form WebPart – Part 4 – Setup the Validation Controls

The data that is being submitted with the Forms WebPart requires validation before it is committed to the database in order to maintain integrity of the information being stored. Doing validation with WebParts typically occurs in two main ways. One can choose to script a separate method in order to validate the entry by using an option like ServerValidateEventArgs.IsValid against the argument, or the inherent validation controls that ASP.NET 2.0 provides can be called in order to validate the information. Considering software architecture concerns and code bloat as a factor, it is typically preferable to use the inherent ASP.NET 2.0 validation options, which will also allow the extension of the validation being used to be assimilated by sister validation controls such as ValidationSummary.

Be aware that when using the inherent validation controls your WebPart will become subject to using client side script as the validation will depend on it. When leveraging the RequiredValidation controls in a WebPart, it will append some JavaScript to the form page on which it is added by calling ValidatorOnWSubmit(). There are known issues when trying to use multiple Form WebParts that use the inherent validation controls. SharePoint will always call the first validation control even when validating a secondary control on the page.

Here, you’re validating a numeric entry manually with a custom method.

[csharp]

            public void ValidateNumeric(object source, ServerValidateEventArgs args)
            {
                try
                {
                    Decimal temp = Decimal.Parse(args.Value);
                    args.IsValid = true;
                }
                catch
                {
                    args.IsValid = false;
                }
            }

[/csharp]

And now, validate input using the native validation controls.

[csharp]

            protected override void CreateChildControls()
            {
                base.CreateChildControls();
                textTextBox = new TextBox();
                textTextBox.ID = “textTextBox”;
                Controls.Add(textTextBox);
                rfvFieldValidator = new rfvFieldValidator();
                rfvFieldValidator.ControlToValidate = “textTextBox”;
                Controls.Add(rfvFieldValidator);
            }

[/csharp]

Share

Use A Builder With JavaScript In WebParts

It is pretty easy to use JavaScript in your WebParts, and people that know me, know I frickin despise JavaScript. I really, really do. I know sometimes I have to use it, but I would prefer if it didn’t exist, even though I might start warming up to our old friend as Orcas since it is supposed to have better debugging and intellisense support (finally). Outside of my personal disdain for it, sometimes I have to use JavaScript (thanks to Trenton Kuzman who wrote my last script for my last WebPart at CENTAF:-) ), and I usually build it out by using an ArrayList object and passing it into a builder method so that I hydrate the builder object in my primary WebPart class file (which traditionally for this layer of abstraction would be kept in a custom WebPart base class that instead inherits from the WebPart base class, assimilated into your WebPart class file subsequently).

So basically, I want to be able to do this in an arbitrary WebPart class file:

[csharp]

private void BuildExampleJavaScript (TextWriter oWriter)
{
oWriter.Write(“Do Something“, ID);

// This is my function below, now I want to add some statements
JavaScriptBuilder l_oBuilder = new JavaScriptBuilder();
l_oBuilder.AddStatement(“function buenz_ExampleFunction(id){“);
l_oBuilder.AddStatement(“try{‘arbitrary Statements}”);
oWriter.Write(l_oBuilder.ScriptString);
}

[/csharp]

It is cleaner to me. So I use this class file:

[csharp]

using System;
using System.Collections;
using System.Text;

namespace buenz.Examples
{
public class JavaScriptBuilder : IJavaScriptBuilder
{
private readonly ArrayList m_oStatements = new ArrayList();

public void AddStatement(string line)
{
m_oStatements.Add(line);
}

public string ScriptString
{
get
{
StringBuilder l_oBuilder = new StringBuilder(100);
l_oBuilder.Append(““);
return l_oBuilder.ToString();
}
}
}
}

[/csharp]

and then this interface (to adhere to Design by Contract programming principles):

[csharp]

namespace buenz.Example
{
public interface IJavaScriptBuilder
{
string ScriptString { get; }

void AddStatement(string strLine);
}
}

[/csharp]

which let’s me do what I want to accomplish. It looks cleaner and provides finer seperation IMHO.

Share