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

Static Versioning in a WebPart EditorPart

Where you put WebPart versioning is something that is up to debate, discussed previously here.

Today a client asked me if it was feasible to construct a custom EditorPart control to display such information in a reasonable manner, so that versioning data could be shown only when modifying the WebPart on the web surface. The code to do this is pretty simplistic, and one can hydrate the versioning either ala Reflection or if desired by using static string literals. Doesn’t really matter.

The first thing is a static method using an HtmlTextWriter consuming two string values representing the version of the WebPart and the friendly name of the product. This could be reflected on within this method if the parameters being abstracted is desired, or supplied when the method is called. I’m just going to use string literals because this is just an example.

[csharp]
public class VersionInfo
{
public static void CreateVersionSegement(HtmlTextWriter writer, string version, string name)
{
var tbl = new Table { HorizontalAlign = HorizontalAlign.Center };
var row = new TableRow { HorizontalAlign = HorizontalAlign.Center };
var versionRow = new TableRow { HorizontalAlign = HorizontalAlign.Center };
var cell = new TableCell { HorizontalAlign = HorizontalAlign.Center, Text = string.Format(“{0}”, name) };
var versionCell = new TableCell { HorizontalAlign = HorizontalAlign.Center, Text = string.Format(“{0}”, version) };
row.Cells.Add(cell);
versionRow.Cells.Add(versionCell);
tbl.Rows.Add(row);
tbl.Rows.Add(versionRow);
tbl.RenderControl(writer);
}
}
[/csharp]

Next, we are going to create a EditorVersionPart superclass that inherits from the EditorPart concrete class. This is the class that will be called from the WebPart superclass, and will leverage the CreateVersionSegement method from above. Because of the class inheritance, we are going to have to implement some abstract inherited methods but are just going to use orthodox filler since we don’t need to implement any sort of behavior for them.

[csharp]
public class EditorVersionPart : EditorPart
{
public string _version;
public string _name;

public EditorVersionPart(string webPartID, string name, string version)
{
Title = “WebPart Versioning”;
ID = string.Format(“MyEditorPart{0}”, webPartID);
_name = name;
_version = version;
}

protected override void RenderContents(HtmlTextWriter writer)
{
base.RenderContents(writer);
VersionInfo.CreateVersionSegement(writer, _version, _name);
}

public override bool ApplyChanges()
{
EnsureChildControls();
return true;
}

public override void SyncChanges()
{
EnsureChildControls();
}
}
[/csharp]

Moving right along, the WebPartSuperClass while inheriting from the WebPart base class also will inherit from the IWebEditable inertface to specify custom editing controls associated with the WebPart control. In the IWebEditable.CreateEditorParts() method we are going to call our custom EditorPart, then supply the requisite string values.

[csharp]
public class WebPartSuperClass : WebPart, IWebEditable
{

public WebPartSuperClass()
{
ExportMode = WebPartExportMode.All;
}

EditorPartCollection IWebEditable.CreateEditorParts()
{
var editors = new List<EditorPart> { new EditorVersionPart(ID, “My WebPart”, “1.0.0.0”) };
return new EditorPartCollection(editors);
}

object IWebEditable.WebBrowsableObject
{
get { return this; }
}
}
[/csharp]

That’s it!

Share

Writing Object Use to Standard Output

A preponderance of fundamental SharePoint proxy objects implement the IDisposable pattern, and therefore the disposal state of such objects becomes a subject of interest, this is predominantly important when using mock object schemes. Recently, I had to do just this and it’s not actually very complicated, but I needed to remember it so decided to post it. While the goal was to make the method analogous to type, the approach can be easily schemed to SharePoint proxy objects, since as you can see it’s a very simple approach.

In the below, the new static extension method TraceUsing in class Extensions is being defined. Since we are going to follow a object, the instance represents type “T” and the Action parameter set to type “T” lets you specify an action to be performed on “T”. In my specific case, the parameter supply to Action was just a write to standard output saying that we are currently using an arbitrary object (to an HtmlTextWriter in my case).

[csharp]
public static class Extensions
{

public static void TraceUsing(this T instance, Action action)
{
try
{
action(instance);
}
finally
{
var disp = instance as IDisposable;
if (disp != null)
{
disp.Dispose();
}
}
}
}

[/csharp]

Share