Returning The SharePoint Start Workflow Link

Building the “Start Workflow” link is pretty straight forward. I am pretty sure there are better ways to do it, but here is an approach when you have to build the link using a string return. How it works is pretty straightforward. Consuming a SPListItem and SPWorkflowAssociation parameter, the SPListItem exposes the ParentList and ID properties and the SPWorkflowAssociation provides the InstantiationUrl and Id properties. The only field level stuff is I was passing a finish url in the query string (_finalurl in the below). When the link is built, it is cleaned up using the inherent SPHttpUtility.UrlKeyValueEncode method.

[csharp]
private string _finalurl;

public static string QueryStringAppend(string url, string args)
{
if (string.IsNullOrEmpty(url))
{
return url;
}
var num = url.LastIndexOf(“?”);
switch (num)
{
case -1:
return (string.Format(“{0}?{1}”, url, args));
}
return num == (url.Length – 1) ? url + args : string.Format(“{0}&{1}”, url, args);
}

protected string BuildWorkflowStartLink(SPListItem listItem, SPWorkflowAssociation workflowAssociation)
{
var builder = new StringBuilder();
builder.Append(SPHttpUtility.UrlPathEncode(string.Format(“{0}/{1}”, Web.Url, workflowAssociation.InstantiationUrl), true));
builder.Append(“?List=”);
builder.Append(listItem.ParentList.ID.ToString());
builder.Append(“&ID=”);
builder.Append(listItem.ID.ToString());
builder.Append(“&TemplateID=”);
builder.Append(workflowAssociation.Id.ToString(“B”));
string url = _finalurl ?? Request.QueryString[“Source”];
url = QueryStringAppend(url, string.Format(“{0}={1}”, FinishIdName ?? “ID”, listItem.ID));
if (!string.IsNullOrEmpty(url))
{
builder.Append(“&Source=”);
builder.Append(SPHttpUtility.UrlKeyValueEncode(url));
}
return builder.ToString();
}
[/csharp]

:)

Share

The SharePoint Federated Identity Process – Part 1 – Introduction

* Throughout this series, Adam Buenz’s Software House  is a medium sized company using Active Directory to authenticate. ARB Security Solutions is a customer of Adam Buenz’s Software House, buying….you know software from them. *

The desire for a business to share various types of resources with others is very common. Yet each business has a different method in place for taking care of issues including security, authentication, and their directory services. Through the use of federated identity though we are able to get passed such barriers. It allows employees to have a standard type of credential that they use to log on to a network.

Let’s put this idea into practice shall we? The basis will be a business known as Adam Buenz’s Software House. We will be exploring how it allows ARB Security Solutions, one of its customers, to share various types of resources through the use of federated identity.

Adam Buenz’s Software House has SSO for the employees to use, so we can move on to the next step in the process. The customers are asking to have an software component order program in place so they can track the progress of what people have ordered from start to finish, hosted in SharePoint. They want it to operate like a SharePoint application that is in their own domain. The sales manager wants to be able to log on using the credentials that ARB Security Solutions has provided him with to do so.

Through such a process, he will have the same access to the information as employees of Adam Buenz’s Software House have. However, the manger of ARB Security Solutions won’t need to have any special credentials in order for this to happen. Adam Buenz’s Software House allows this because they don’t want the responsibility of maintaining any account for another company that happens to be using one of its applications.

Share

Coding With SharePoint SSO, Part 1

In this series of three posts, I will attempt to introduce working with the SharePoint Single Sign-On service from a more programming standpoint, and I will pepper in some of the administrative and configuration stuff because I haven’t seen it covered very well at all, either on the web or in books. I will firstly be going over the basic programming stuff in this post, and then we will begin to explore the more advanced SSO programming concepts, and hopefully at the end you will have a viable solution that you can put to work in your environment.

The SharePoint Single Sign-On functionality is provided through the Microsoft.SharePoint.Portal.SingleSignon namespace, however we will be deriving some other minor functionality from other namespaces as well during the duration of this series. Therefore, when working with the Single Sign On functionality, you will have to import this namespace by making a “using Microsoft.SharePoint.Portal.SingleSignon” reference at the top of your class file.

When approaching the Single Sign-On service programmatically, there are some important differences to take account between the 2003 and 2007 version of SharePoint. Most importantly is the concept of pluggable providers, where the default SSO provider can be replaced with a custom SSO provider assuming that the appropriate interface is inherited from within the custom provider. This type of pluggable functionality allows a developer to provide an architect with a more tangible solution whereby the provider effort can be tailored to the environment without attempting to structure the default SSO service towards a specific need, a very powerful option indeed.The primary interface that the developer has to become accustomed to is the ISsoProvider interface, which, since the provider model is pluggable allows a developer to specify an arbitrary provider. When pooling the provider, you will also be using the SsoProviderFactory class that is offered through Microsoft.SharePoint.Portal.SingleSignon, which contains the GetSsoProvider method, which will return the current provider that is implemented within your MOSS environment. Therefore, your first method call will be structured as such:

[csharp]

ISsoProvider l_oProvider = SsoProviderFactory.GetSsoProvider();

[/csharp]

The above, when added, as stated, will get you the current provider that is implemented with your MOSS implementation. Following, let’s actually start to retrieve some data from our SSO provider, namely, let’s start snagging some credentials!

In order to harvest credentials, we are going to use the ISsoProvider.GetCredentials method provided out of the Microsoft.SharePoint.Portal.SingleSignon namespace. There is as a string argument this is going to take, the application identifier, which is generally know as the Enterprise Application Definition (more commonly known as an EAD). Therefore, you will have to know what this literal string value is, and it must be in place before you start programming against your SSO environment. Here is an example of starting to use the GetCredentials method, using the previously declared provider object:

[csharp]

SsoCredentials l_oCredentials = l_oProvider.GetCredentials ( “HereYouShouldUseYourEAD”);

[/csharp]

When error handling this type of programming tasks, there are some very specific exception types that you can use in order to ensure that the exceptions that you return are correct, and provide more value with your software than orthodox system exceptions. For catching generic SSO system exceptions, it is advisable to use the SingleSignonException object, since it will return an error code that will help you trouble shoot specific exceptions more efficiently.

[csharp]

catch (SingleSignonException l_oException)
{
}

[/csharp]

For handling method level exceptions, such as when using the GetCredentials method as described in the above, you should use the more specific exception types, namely the SingleSignonCredsNotFoundException. This exception type takes on the form:

[csharp]

catch (SingleSignonCredsNotFoundException l_oSSOException)
{
}
[/csharp]

Ok, that’s enough for now, in the next post, I will deep a whole lot deeper into programming SSO, and maybe do a prequel to this post for how to correctly architect an appropriate SSO environment.

Share