A way to think about Security Policies

Anyone who has done any configuration within Click Commerce Extranet has most likely had to configure the security policies. These policies are an essential part of any fully configured site. It’s those policies that define who can access project information, perform Activities, interact with Reviewer Notes, and view information in the project’s audit trail. Proper configuration of Security Policies is critical to your site’s success for two primary reasons: Making sure the right people can do the right things at the right time and avoiding poor performance.

Even if you’ve configured security policies before, this post should be useful as it describes a way of thinking about how best to configure your policies.

Phone, Web Conferencing and Email are all inferior

As I sit here in the Detroit airport facing a 4 hour delay and scheduled arrival back in Portland at 2AM PST, it would be easy for me to rail against the need for face to face visits, but I won’t. It’s incredibly valuable to get together with the team who is ultimately responsible for delivering solutions and countless updates of those solutions to a user base that is always asking for more. In fact, my visit with just such a team this week at University of Michigan only serves to reinforce my belief that there is no replacement for the occasional face-to-face get together. Phone, Web Conferencing, and Email are all inferior to physical presence.

Context is king when it comes to security

This friendly little reminder comes via Scott Mann from University of South Florida:

I found something in our site that I wanted to pass along for the benefit of your developers (yes, we’re still finding stuff).  Today’s issue is that we were getting email failures for people we knew had access to projects.  They were failing on the Reschedule activity which is supposed to notify the PI and reviewers that the project has been moved to another meeting.  Unfortunately, the notifications were configured on the activity, whose read policy properly blocks the PI since the form displays the names of reviewers.  Since the notification’s context is the activity, and the recipient does not have access to the activity, the notification fails. It’s an easy mistake to make, but a good lesson for understanding the impact of activity security and the importance of context.

First let me say thanks to Scott for his contribution. It’s nice when others write my blog posts for me. ;-) This is a first but hopefully not the last (hint, hint, nudge, nudge). Scott is absolutely right and makes a point that I think deserves further elaboration.

Tips for managing WebrCommon files

Today’s post is short and sweet and I hope will save you a headache or two down the road. It’s related to managing the contents of your WebrCommon directory.

Tip #1
As most of you have already upgraded to Extranet 5.6 or are actively working your way there, it’s a good opportunity to emphasize that the best way to add or update your WebrCommon files is through Site Designer. This is especially true with Extranet 5.6 because, as of that release, the Click Commerce Extranet framework actually manages two locations for the WebrCommon files. In the past you were able to get away with simply dropping files directly into appropriate directory in the Windows file system. With the addition of the new location, this isn’t enough and can lead you to scratching your head about why your newly updated custom.css file doesn’t seem to be working. If you drag the file into Site Designer, on the other hand, all the locations are updated correctly. More information about the changes to WebrCommon in Extranet 5.6 can be found in this article: HOWTO: Manage the Webrcommon Directory in Extranet 5.6

Even in Extranet 5.5.3, there are benefits to dragging and dropping in Site Designer. Using this approach instead of direct file system access will avoid issues related to WebrCommon files that have their file attributes or permissions set in such a way as to break backup/restore or use within your site. Dropping the files into WebrCommon via Site Designer causes them to set up correctly.

It’s as easy as Drag-and-Drop.

Tip #2
Since you are updating the contents of your WebrCommon directory, I can safely assume that you are doing this in your development store that is integrated with Source Control (right?…please tell me I’m right!). This means that any new files need to be added to your version repository as well. In most cases, Process Studio is the tool you use to do this, but there is one exception and that is with Binary files such as images. In the case of binary files you should use the Visual Source Safe client directly to add or update them. This is because Process Studio makes the assumption that files are textual. This assumption doesn’t work too well when they aren’t and can result in images not looking right. Once in source control, however, there are no concerns about them being included in your next configuration update and being correctly applied to your test and production stores. Support for binary files will be added to Process Studio with the release of Extranet 6.0.

Cheers!

Three paths to an authenticated session, Part 4: Single Sign-On

If you’re just joining this topic, take a peek at:
Part 1: Introduction
Part 2: Built-In Authentication
Part 3: Delegated Authentication
Your users interact with more than one online application within your institution. To do otherwise is just plain unusual these days. Perhaps you have one application for IRB processes and another for Grants. Then there’s your information portal, ordering system, Accounting System, HR system and a whole host of other possible applications. This is the reality of today’s world. While the universal goal is to put everything a user needs within arms reach, the unfortunate truth is that the Swiss Army knife approach to life in a research Institution is difficult to achieve in a single application. Next best thing is integrating different applications.
Click Commerce Extranet certainly is a great step in that direction because it enables you to put many Research related activities under one roof, but there will always be other systems. Once we accept this, the real question is how do we make this easier on the users? One pain point is the need to continually have to identify yourself to each system by logging in. Thankfully this is a very easy problem to solve by implementing Enterprise Single Sign-On (ESSO).

Three paths to an authenticated session, Part 3: Delegated Authentication

If you’re just joining this topic, take a peek at:
Part 1: Introduction
Part 2: Built-In Authentication

If Built-In Authentication doesn’t strike your fancy, then you’re in luck. Click Commerce Extranet provides the flexibility for you to roll your own using an External Authentication Data Source. The two most common approaches are to use LDAP or Active Directory, though nothing prevents you from using any other source, such as an external database, your HR system, etc.

The Extranet Authentication Process

As mentioned in the last post, all access to an authenticated page must first go through a login page. This doesn’t mean, however, that the user will ever see the login page. At the heart of this page is the Login Component. On that component exists logic that is executed as the login page is being rendered to facilitate both Delegated The following steps are performed:

1. Check to see if the user is externally authenticated
   
2. If not, present the Login form and collect username and password
3. Authenticate the user externally
4. If unsuccessful, authenticate the user locally
5. Create authenticated session

In delegated authentication, the user is presented the Extranet login screen and asked to provide their credentials. These credentials are then validated against an external data source, such as LDAP. All Extranet does, however, is call a method that is intended to be overridden to contain whatever you need to do to authenticate the user.

If you launch Entity Manager, you will be able to find an Entity Type named “ExternalConnector”. This is an abstract EType.
Customizations should subtype this to implement single-signon
and other forms of external or delegated login authentication.

The method that Extranet calls to allow you to externally validate the provided credentials is “authenticateUser(userID, pwd)”. This method needs to return either true or false. If the return value is false, the authentication fails and an intentionally generic message is displayed to the user to communicate this fact. If the method returns true, the caller retrieves the logged in user now associated with the current session; if there is one, it presumes a successful login has been accomplished, otherwise it proceeds to perform the login itself, validating the credentials as a standard Extranet user.

You can see a basic template for the method here. The ExternalConnector Entity Type also includes an excellent description of the authenticateUser method.

Once you have created your subtype, you need to inform Extranet which subtype to use. This is done by setting the value of a shared attribute named “externalConnectionType” on CustomUtils. This attribute contains a string which is
the name of the EType which subtypes ExternalConnector.  By default the value is “ExternalConnector”.

To enable delegated authentication, perform the following steps:

1. Locate the Entity Type named Customutils in Entity Manager
2. Right click CustomUtils and ‘Edit Entities‘ change the externalConnectionType to be the name of your new subtype of ExternalConnector instead of ExternalConnector
3. Save your changes

Once complete, your Delegated Authentication implementation should be able to handle the following cases:

• User in Extranet but not in external authentication source
• User in Extranet and in external authentication source
• User not in Extranet and in external authentication source
• User not in Extranet and not in external authentication source

Of course, there are a few details left out in this post such as the specifics of how you connect to your external authentication source and validate the user credentials. Those details vary by implementation. By far, the most common external source is LDAP or Active Directory. Click Professional Services has plenty of experience in implementing Delegated Authentication and can get you up and running quickly. If you’re interested in enhancing your site in this way, just let us know. We’ll be glad to help.

Cheers!

Three paths to an authenticated session, Part 2: Built-In Authentication

If you’re just joining this topic, take a peek at: 
Part 1: Introduction

By default, Click Commerce Extranet based sites allow a user to sign in using built-in authentication. This means that the site presents its own login screen and all user account information, including user ID and password, are maintained within the site’s database. The user will be presented the login screen in one of two cases:

• When browsing a public page, the user clicks the login link in the upper right corner.
• The user attempts to access a secured page directly. For example, they click a link to a project workspace in an email notification.

In both cases, the user next sees a page with the user ID and password prompts.

Did you know that you can make your own login page? The login fields themselves are presented as part of the Login component which you can place on any page. In the starter site, there is an entire page dedicated to login, but that’s just a configuration choice. Other sites have also put the login component directly on their home page.

When an anonymous user requests access to a secured page, Extranet will redirect them to the page where they can login. The page they are sent to is configured on the secured page or one of the pages up the page hierarchy from there. One of those pages must have a login page defined for it. The settings are found on the Properties dialog for the page.

At a minimum the root page in your site needs to have a login page configured for use by all pages, but you have the option of creating additional login pages for use in different sections if you wish. Extranet will redirect the user to the configured login page whenever authentication is required and will look something like this:

With built-in authentication, the user is required to enter a valid user id and password. Extranet then uses this information to authenticate the user against the local database. If authentication fails, a message is displayed, otherwise, the user is redirected to the page they were originally trying to reach. If the original URL is the default URL for the site, or the user clicked the login link themselves, they will be directed to their default page once authenticated. In most cases this would be their personal page.

At the time the login page is rendered, there are a couple of additional checks that are made to determine which authentication approach is to be used. As built-in authentication is the default, you don’t have to do any additional configuration to allow your users to login (other than to make sure they have accounts, of course).

Use of Built-In Authentication also makes it easy to use several other built-in features that you can configure via Login Policy administration or the Login Component including:

• Remember Me
• Password Policies
• Forgot User ID and Forgot Password feature
• Account Lockout Policies
• Terms and Conditions
• Legal Notification

In the next post, I’ll explain what is required to enable delegated authentication.

Cheers!

Three paths to an authenticated session, Part 1:Introduction

Very little of what Click Commerce Extranet is used for is done without first knowing who the user is. Anonymous access to the site, if allowed at all, is typically restricted to a small amount of general information from the Office of Sponsored research that is intended to be public information. All the real work done in the site requires that you first identify who you are. It’s only by the site knowing the identity of the current user that it can apply security policies, present pertinent information, and guide them along their unique path through the workflow processes.
So, given that, how does a user uniquely identify themselves? Click Commerce directly supports three paths:

1. Built-In Authentication
2. Delegated Authentication
3. Enterprise Single-Sign-On

Built-In Authentication

Click Commerce Extranet includes integrated authentication which involve the user being presented with a login form where they provide their User ID and Password. These credentials are then verified against the user information stored locally within the site’s database. To use this all you have to do is define your users in the site and the rest is already in place.

Delegated Authentication

As an enterprise application, Extranet also supports the mode where the authentication is performed by validating credentials against an external source. Common examples of this are LDAP and Active Directory but need not be limited to those. The real difference with this approach is that passwords are not maintained in Click Commerce. Instead they are maintained as part of an external user authentication data source. The user is still presented the Extranet login screen so that the User ID and Password can be provided but this information is then delegated to an external authentication service. Once authenticated externally, the user is allowed into the site.

Enterprise Single-Sign-On

Taking advantage of ESSO means that all elements of authentication are performed external to Click Commerce Extranet. While there is no standard approach that all implementations use, the most common approach involves a technique I call “Intercept, Authenticate, and Redirect”

• Intercept – Any request for a secured page within the site is intercepted by an IIS Filter installed as part of ESSO. The user is then presented with a login form owned by the ESSO implementation. This is not the Extranet login screen.
• Authenticate - The user provides their credentials into the ESSO Login screen which is then authenticated against the authentication source. This source can be anything, including Active Directory, LDAP, or a facility provided by the SSO vendor. From the perspective of Extranet, it really doesn’t matter.
• Redirect - Once the user is authenticated, the ESSO product will insert a unique identifier for the user into the HTTP Request Header then redirect the user back to where they were originally trying to go in the first place. This time, Extranet will be allowed to handle the request. At this point the user has been authenticated externally but that doesn’t mean that they have already established an authenticated session within the Extranet site. This is handled in Extranet by retrieving that unique identifier from the HTTP Header and using it to look up the user in the local Extranet database. If there is a match, Extranet will create an authenticated session for the user and allow them in.

This may seem like a lot but the Extranet portion of the implementation is accomplished in a single method which extranet automatically calls during the authentication process.
Some examples of ESSO packages include Shibboleth, Pubcookie, Cosign, Computer Associates Site Minder, and Tivoli TIM/TAM.
All three approaches have advantages and disadvantages but as a set of options, cover all of the authentication approaches we’ve seen to date. The decision to use a particular approach is often made for you by institutional policy or your central IT group.
This was just a high level introduction. In subsequent posts, I’ll be digging into how to leverage the integration points provided by Click Commerce Extranet to allow your site to easily plug into to any of these authentication approaches.

Part 2: Built-In Authentication

Cheers!

What’s new in Professional Services

With only one week before the annual Click Compliance Consortium meeting in Chicago, the office is buzzing. The agenda is firming up and it looks like we’ll be hovering near record attendance levels. Each CCC has it’s own flavor thanks to the fact that it’s really an event hosted, presented, and attended by members of the consortium itself – yes, that means you. Of course there’s always the expected presentation by those of us at Click Commerce, but it’s learning what all of you are doing and the free exchange of ideas that I look forward to the most.

This year we’re trying something different that I’m excited about. On the second day the agenda splits into three tracks and we all get to spend a couple of hours in an open discussion about one of three topics: IRB, Grants, or Animal Operations. I, with the help of a couple of customers, will be moderating the Animal Operations discussion and I hope those of you with interest will be able to join in on the conversation. I hoping that this will be a lively session.

Closer to home, I’ve been continuing the drive to refine our development practices. I’m not quite ready to share any results but here’s a short list of things we’re working on:

Formalization of best practices related to the development of reports using SQL Server Reporting Services.
We presented on this at C3DF and I’ll touch on it again during my CCC Reporting presentation. We’re currently experimenting with different applications of this technology so that we can determine the situations where it is a good fit and, equally important, where we would recommend other approaches.

Automated Testing
I’m especially excited about our early progress on this topic. One of the biggest challenges in any enterprise scale development project is knowing that the most recent change has no adverse effects. Did this cool new enhancement break any pre-existing capabilities? What is the performance impact of this new enhancement? We’re currently implementing automated tests for a large IRB project using three open source tools (Cucumber, Watir, and Celerity). It’s amazingly rewarding to push a button and see the browser run through an entire workflow scenario without any further assistance from me. I’ve come to really like the color green, which is what the final report shows for tests that pass. When I see red on the other hand, representing failed tests, I get a strong urge to immediately make it green. I’ll definitely be blogging more about this in the future.

Introduction of Agile development practices
One of my own personal goals is to improve the way information flows from Project Manager to developer, provide a more real time snapshot of the status of the project, and establish good development techniques early in the project before the stress level is too high to want to try something new. For all of these reasons, I’m a fan of an Agile development methodology. In my mind, the development model I prefer is to establish a routine from the beginning of the project which is based upon a repeating cycle of development that involves these elements:

• Establish 3 stores: Development, Test, and Future Production. The development store is integrated with Source Control from day 1 and implementation is broken down onto 2 week iterations. At the end of each iteration a patch is created and applied to both Test and Future Production.
  
  Test is where all user acceptance testing takes place. Testing on the development store is limited to the developer’s themselves testing each other’s work as part of unit testing.
  
  Future Production starts out as a pristine store, empty of all data and is given the white glove treatment. As patches are built after each iteration, they are applied to this store to keep it up to date. In this way, we have a clean store to use when going live without first having to worry about clearing gout all the data that collects through the course of development and testing.
• Only update Test and Future Production via patches. This means that the same process we recommend once your site is live is enforced early in the project. In my mind this has many benefits. It means that by the time you go live, this process is second nature and it avoids the “deer in the headlights” feeling of being asked to introduce this process at the time of going live, which is a time when you are already stressed about a lot of other things.
• Test incrementally. Thinking about how to test the entire system all at once is a bit frightening. Though the process of applying patches after each development iteration we can parcel out the testing burden and at the same time get end user feedback much earlier in the development process when there is actually time to properly respond.

As a part of this effort, we’ve also been piloting the use of a new tool to help us track all the development and so far it’s being received well. At the end of our pilot, I’ll post a summary of our experiences and conclusions.

I look forward to seeing all of you at the CCC conference next week in Chicago!

Cheers!

Script Editor Extensions for Extranet 5.6

One of my first posts to this blog was to announce the availability of an experiment I was working on to enhance the Workflow Script editor so that it supports syntax highlighting and automatic indentation. The experiment worked well enough that several of you gave it a try and are still using it even today. That’s not to say there weren’t rough edges and annoyances. There most certainly were, but I told myself that if I were to revisit this experiment again, that I’d keep those in mind.
Recently, I’ve been wanting to update the editor so that it was compatible with Extranet 5.6 and this weekend I took the time to do just that. I’m happy to announce version 2.0 of the Script Editor Extension.

All previous features were retained:

• Automatic Syntax Highlighting for JScript
• Automatic indentation according to JScript syntax rules

Version 2.0 includes some new features too:

• Extensions for both the Workflow Script Editor and the Command Window
• Completely rewritten to avoid inclusion of base Extranet pages in the Script Editor Extension download package. This does imply making a minor change to the standard editor pages but it is as simple as adding a single symlink. Nothing already on the base pages is altered in any way. My hope is this will make it easier to adopt new base enhancements as they are released.
• Deployable as a standard Update via the Administration manager
• Automatically resizes the editor as the page is resized
• The color scheme used for syntax highlighting matches the standard color scheme used in Site Designer and Entity Manager.

If you are already on Extranet 5.6 and are interested in giving this a try, just download the package and follow the included instructions.
Though this is provided as-is and is not part of the standard product, I’d love to hear your feedback. I plan to use this myself and if you encounter any issues, there’s a good chance I’ll post updates.
Cheers!