MOSS Internet Site - Security

Building a corporate Internet site using MOSS has real security implications. Access from the Internet (for the users) and from within the organisation (Intranet) must be considered in terms of both authentication and authorisation. Although a sound solution, MOSS is not well documented here and an implementation typically needs to be designed. Following is a suggested solution template for organisations to use when attempting this. It should resonate with the majority of MSFT-shop organisations moving to a MOSS Internet site solution.

The solution supports two basic user categories:

1) Internal users. Employees accessing via the Intranet. Typically content authors - in charge of maintaining solution content. It is recognized that a requirement for employees to maintain content via the Internet (from home?) may well exist. In this situation, they should connect to their Intranet using whatever connectivity solution is already in-situ (VPN?). Although it is certainly possible to allow employees to manage content directly over the Internet, this creates additional complexity, cost and security risk for perhaps the sole benefit of; being able to manage content from an “unofficial” desktop (without the connectivity software) e.g. in a cybercafé.
2) External users. Public users accessing via the Internet. Able to access content only. May be further categorized as either - Anonymous user (Read only/Able to access all public content) or Registered user (Read only/Able to access special content in addition to public content).

The solution supports two-way authentication; one to support internal users (NTLM) and the other to support external users via Forms Based Authentication (FBA). Internal users are authenticated using the SSO (Single Sign-On) feature provided by the LDAP directory services. An internal SSO process synchronises the Intranet AD with a De-Militarized Zone (DMZ) LDAP. In practice, this will mean that an internal user can log onto the Intranet and be pass-through authenticated to the DMZ i.e. they will not have to log in twice.

Synchronisation between the Intranet AD and DMZ LDAP is one-way. This means that the creation of new internal users will have to take place on the AD and not directly in production. Assuming your organisation does not need to use profile import for LDAP users (and also does not provide custom profile properties for its internal users), it will only need to cater for authentication of LDAP users. This is perhaps a minor risk, since it will only be possible to test this once deployed in Production.

Similar to traditional NTLM authentication mechanisms, the FBA application requires a centralized store for external user credentials (in this case - SQL database). Internal user credentials are stored in AD (on the Intranet) and in LDAP (within the DMZ). An internal SSO process synchronizes them. No authentication is required for anonymous external users as you would expect.

User information stored in the SQL database is created only by a single registration process. A registration page defines the user information and the related validation. Using FBA, users will remain authenticated until the user closes their browser or until authentication timeout occurs.
 
Moving onto authorisation; authorization policies are required for granting content access rights for differing user categories. As stated above two different “extended” web applications are defined for managing both internal and external users. Authorization policies are applied to those distinct “extended” applications addressing the user categories’ tasks.

In the “extended” web application defined for the NTLM authentication (used by internal users) two different user groups are defined in the site settings permission section - Site Administrator (users with full control access rights) and Content Authors (users with design control access rights). No Anonymous access is supported in this “extended” web applications instance. In the “extended” web application defined for the FBA authentication (used by external users) all users are defined as users with read access rights. Anonymous access is supported for a subset of content as appropriate.

A final note on domains. The AD within the DMZ is for service accounts only e.g. SQL or MOSS services. It is not possible to trust the DMZ AD and the organisation AD proper. The DMZ is also unconnected to any other organisational system. MOSS based content deployment into the DMZ is unsupported. These measures should address internal security concerns. There are plenty of other security hoops to jump through when creating a MOSS Internet site but the above should get you started.

Universal enterprise UX – Part 7 (Browsing, finding & copying)

Unless we implement a duplicate create button in the Type/Filter web-part, we would have to first select an existing Enquiry (or any other business data) in order to create a new one. Each form will have its own individual buttons but they should all contain the basic functionality indicated above ideally with the buttons placed in the same positions on the form.

When we see information on a form, it is likely that the user will want to browse (or drill-down) into the detail of that particular business entity e.g. an Enquiry. There are several options available to us to handle browse.

1) Consolidated View button. We would require this button in order to see more detail surrounding a particular piece of business data in a form. For example, if a particular note were displayed in a list-box of all notes for a particular Enquiry, clicking “View” would open up the Wizard Pane to give more details regarding that particular note without losing context with the Enquiry proper.

2) Multiple View buttons. This is as per the above except that each control capable of being drilled-down into has its own View button. The user would only be able to examine in detail the particulars of one business datum at a time on a form, so it makes sense to have just one (consolidated) view button rather than cluttering-up the form with one View button per-datum. The disadvantage of both of these approaches are that they disrupt standard hyperlink flow, for example; if the user sees an Order Part in a list of linked Order Parts, he has to select it and then select “View” in order to see it in detail. The advantage is that the linking process is simplified as the user doesn’t need to differentiate between the links i.e. the row containing the Order Part and the control i.e. the list-box containing all Order Parts.

3) Separate the hyperlink from the control. This would be required in order to both allow regular hyperlink operation but differentiate between this and the user merely wanting to change the value. If the user wanted to change the value in a control he would click the area of the control not covered by the hyperlink. If he wanted to instead drill-down into the value in the control, he would click the hyperlink instead. The main disadvantage is that the user needs to be aware of the difference and this is not typical UX behaviour. It also means that the user can drill-down into several values without losing focus upon a particular control. The main advantage is that all hyperlinks work in the regular manner.

Option 3 (Separate the hyperlink from the control) option is selected for our model; principally because this way means that we do not have to compromise on standard hyperlink operation.

In the case of the Enquiry example described above, the Wizard Pane did not have to be used to provide the detail view; although in the case of viewing the details of notes, which do not have a lot of information around them; this is recommended. An alternative approach would be to (upon View click) re-purpose the entire Browse/Next web-part to display the detailed information and provide a “Back” button towards the bottom of the form. In this way, much more screen real-estate can be used to display the detailed information; although this is at the expense of context i.e. Enquiry details will be temporarily hidden to accommodate the new details. This type of behaviour would be recommended for viewing the details of the principal business objects e.g. Enquiry, Task, Order, Order Part only.

The model uses existing Find and Browse UX components in order to find entities in forms, for example; finding a particular Contact from the Asset Filter (a Type/Filter UI component) to add to the Task Details form. This allows us to: Reduce development time; as additional find and browse capability is not required; Reduce testing efforts because the principal controls need only be tested once; Reduce training efforts as the user knows to always go to the Asset Browser to find assets (Customers, Classifications, Products and whatever else is deemed an asset in future) and finally - obtain data entry speed benefits as the user’s flow of operation is consistent. It also lends itself more readily to macro-automation.

Several options around implementing find functionality are available:

1) Accept loss of Type/Filter status. When highlighting a control on the form i.e. Contact details. We just go to the Asset Filter and choose the correct Contact Id to add to the form, clicking “Link” to add it to the requisite area on the form highlighted. Benefit: Don’t need a new button. Benefit: Can use existing one-way line of web-part communication i.e. from Type/Filter to Display/Update web-part. Drawback: Lose focus upon whatever was previously highlighted in the Asset Filter (Type/Filter) e.g. Particular Products of interest may have been in the Asset Filter; these may have had lengthy filter criteria which, if the user wants the list back, will need to be re-entered.
2) Add “Find” button to form. This would temporarily re-purpose the Asset Filter in order to find the Contact that is needed to add to the form. Clicking “Link” would in addition to putting the selected Contact or Contacts in the form, place the Asset Browser back into the state it was previously. Benefit: Don’t lose focus upon whatever was previously highlighted in the Asset Filter. Benefit: The “Type” and “Context” fields in the Asset Filter could be temporarily propagated to show correct context e.g. Type of “Customer” and Context of “Contact”. Drawback: Means that we have to build an additional line of web-part communication i.e. From Display/Update web-part to Type/Filter. This could be challenging if the Display/Update web-part is rendered in an iFrame.
3) Add “Save” button to Type/Filter. This would save the state of the Asset Filter (Type/Filter) before operating as for 1 above. Once at state is saved (only one state allowed to be saved), the button would turn into a “Restore” button, allowing the original state to be returned i.e. after we have located and added the correct Customer(s). In this way, it would operate much like the memory function on a regular calculator. Benefit: Adheres to the existing channels of web-part communication i.e. from Type/Filter to Display/Update web-part. No new channels required/means no additional testing required. Benefit: Provides additional functionality as a consequence of finding things e.g. a user could find some interesting Products and save them before looking at some Customers and then toggling between the two without even involving the Display/Update web-part and form filling. Drawback: It is an additional control to place upon a Type/Filter and so may add to general application complexity.

Option 3 (Add “Save” button to Type/Filter) is selected for our model due to this solution giving the user more power without adding behind-the-scenes complexity and risk.

The Type/Filter should also be used to copy things from one UX component to another. In this way, it is an extension of the method used to find things. For example, if a requirement exists to copy one or more Order Parts from one Order to another, the user would select the Order that he/she wants to copy to (bringing it up in the Display/Update web-part) and then switch to the To-Do List, selecting type of “Order” with a context of “Order Part”, clicking “Filter” and then selecting the checkboxes of the existing Order Parts to copy to the Order under focus and in the Display/Update web-part. It may be seen that the user can only copy things that are selectable in a linked Type/Filter through the standard filter options. If business elements outside of this selection are required, filter options should be changed to encompass the required selection rather than implementing some new copy/paste option. Filter options are easily changed as they are defined through exposed web-part properties.

Universal enterprise UX – Part 6 (Form Development)

Form development is the bulk of programming activity using our model. The Type/Filter and Browse/Next web-parts should (in theory) be able to be configured (XML/web-part properties) rather than developed. Forms can be developed using whatever technology the organisation are familiar with e.g. Web/InfoPath/X.

The Browse/Next web-part is the wrapper that all forms reside within (when they are on screen). Many forms will be able to be rendered within it in their entirety. Some forms will require contextual information to be retained in the form for reference, while the user is engaged in an “offshoot” task; for example a form focused upon generating a new user might want to retain the core user details e.g. Name, ID on the Browse/Next, while also taking the user through a process to add that user to selected user groups. This sort of behaviour should make use of the Wizard Pane concept. This supplementary web-part permanently exists on the screen wherever a Display/Update web-part is placed and (like personalisation behaviour) expands whenever required.

Its use is not limited to wizard-like behaviour and it may be used to render discrete pieces of information, tables or other complex controls that require the original context (in the Browse/Next web-part) to be displayed at the same time that the user is interacting with the new process. Another example of use of the Wizard Pane would be to show details of Notes, where upon selecting the note in the list box (perhaps attached to an Order); the details of that note e.g. Name and Description, Raise Date, Raiser and Type are detailed in the Wizard Pane.

Form developers should be fully aware of the Wizard Pane and make appropriate use of it where necessary. Judicious use of the Wizard Pane could dramatically improve the UX. A good form developer will make appropriate use of it wherever possible.

When the Wizard Pane is expanded on a page, it will “compete” for space in the same way as for the other web-parts. Within a form, collapsible sections should be used wherever a logical grouping of form details exists, for example; “Personal details”. This allows the user to personalize the form experience by collapsing sections he is not interested in at a particular time. The combination of both the Wizard pane and collapsible sections should mean that use of tabbed dialogues and in particular pop-up dialogues should not be necessary within any application built using this UX model.

Universal enterprise UX – Part 5 (Personalisation)

All commercial portal platforms allow for a level of personalisation; for example Windows SharePoint Services (WSS) allows the user to change their personal view of a WSS site e.g. resizes of web-parts, addition of new part-parts, minimising of web-parts.

Our model needs to extend this however. For example; when a web-part is minimised, the remaining web-parts should automatically re-size to consume as much of the screen real-estate as possible. This auto-expansion activity must only be constrained by underlying portal platform e.g. web-part zones for the page in question using WSS/MOSS. Unless all web-parts are specifically minimised, whatever web-parts are not minimised on the page, they will always consume exactly the same screen real-estate.

Examples of auto-expansion behaviour follow. These are not exhaustive and additional combinations may be allowed for example a page where the Task List is auto-expanded to consume the whole page (similarly to the Asset Filter whole page expansion below) would be possible.

Darkt-gray boxes above indicate that a web-part has been minimized by the user. Light-gray boxes indicate that a web-part has automatically re-sized itself to consume the available space within its web-part zone. Note that in the case of the page described in the top-right above, the Asset Browser has not horizontally expanded to fill the page, as this would exceed its web-part zone. Note also the lines between the pages as they indicate how a page may be successively personalized to the user’s taste.

Universal enterprise UX – Part 4 (Bringing it to life)

Fleshing-out our order processing scenario a little; Orders consists of Order parts (Line items) and these are for various Products. Products grouped into Categories. Enquiries can be progressed into Orders and Tasks are tracked by the application for various reasons e.g. Tracking cold calls, customer complaints etc. All key entities are allocated a Classification e.g. Geography. Customers are front-ended using the order processing system but are likely managed using something else. Similarly Tasks are front-ended but this will likely be managed by some workflow solution. That is it - a standard order processing solution.

Several instances call for a non-linear browsing approach, for example, the selection of Categories and Products where related items (not specifically searched upon by the user) may be seen and the selection may be seen in context. In many instances, the user will also want to search upon these objects (Categories and Products) directly i.e. without browsing.

The arrows show UX contextual flow only. For example, user interaction in the Browse/Next web-part will not automatically affect the Order browser however; the user can select a business operation such as “Add to order” to insert a Destination (or any other allowed object) into the Order browser (and the corresponding Order [Part] highlighted).

Each Type/Filter type of web-part will operate as a three-fold UX process. The user will choose the type of data to work with (Step 1) then apply a series of general filters to that selection (Step 2) and then browse the result set (list box) by use of the vertical scroll-bars and column sort functionality (Step 3).

Initial rendering of the Type/Filter web-part (Step 1) should either default to the filter view (Step 2) or the list view (Step 3). As such this web-part has just two modes – filter mode (Step 2) or list mode (Step 3). Three steps are shown above in order to articulate the UX process involved i.e. the Type has to be chosen first.

In this (modal) way, the model can affect a search by the following means – filtering, sorting and then browsing (from switching from the Type/Filter web-part to the connected Browse/Next web-part). For both UX and performance reasons, a more unstructured search function where, for example, all matches for a particular string are returned across all tables, columns and rows will not be selected. This type of unstructured search is more appropriate to content searching.

A Task is selected in the Task list and the matching Task is automatically selected in the Browse/Next web-part (Order web-part) below it (with the hierarchy also automatically expanded for browsing). The Next functionality will be grayed-out in this particular case, as there will only be one matching Task amongst the Orders.

We would mainly use the Type/Filter web-part as an entry-point to the browsing (what users generally really want to do). For example, if we know which State we want, we will use the Type/Filter web-part to select a Level of “State” then switch to the list view to find our particular state e.g. California. Once we have selected this, in the same manner as with the Task description above, we would switch to the Browse/Next web-part to drill-down into California to see the regions within that State and the Cities within the Regions (or in fact any hierarchical description we define below California; political/ethnic etc.).

Find functionality to the Type/Filter may be extended by the provision of two Filter/Value pairs, the first of which has previously enumerated values i.e. in a drop-down, the second of which displays different Filters (fields) to the first and allows a “wildcard” search via a text-box.

If the user wished to search for all Marketing Tasks for the New York office created for customer “Smith”, they would enter the following; Type = “Task”, Context = “Marketing”, Level = “”, Filter = “Office”, Value = “New York”, Filter = “Customer”, Value = “Smith”. There is a purposeful and direct parallel with the underlying table structure e.g. Type = Table, Context = Table Type, Level = Table Relationship, Filter = Field, Value = Value of Field.

No additional placement of Filter/Value pairs is possible with the model above. Also note that no Boolean operators are operative between the Filter/Value pairs. Of course more pairs/Boolean operators would extend functionality but would your users really use them?

Universal enterprise UX – Part 3 (Some rules)

For purposes of both user acceptance/reduction of technical complexity, rules regarding the use of web-parts on a page should now be enforced for our model:

1) No more than six web-parts on a page by default. The user may well be able to add more web-parts from a gallery but this should be at his/her discretion. By default, any more than six on a page risks disorientation.
2) Web-part communication only goes one way. Although certainly technically possible to have web-parts communicate both ways, i.e. both to and from each other. This creates unnecessary complexity i.e. users have to think modally also it increases the number of paths through the system which then have to be tested.
3) One web-part should communicate with a maximum of two other web-parts. Although generally desirable to have web-parts communicating with each other, any more than two other web-parts being “automatically” changed when a user selects an item in a third web-part is making the application too linear i.e. it prevents other activity from happening in parallel because UX components have just been re-purposed for the current task under consideration. Allowing for a level of UX multi-tasking is desirable.
4) No more than one Display/Update web-part per page. Any more than this would entail either a significant amount of scrolling or would be confusing to the user as two portions of the screen would then be devoted to displayed information. Which Display/Update web-part should they look at, for example, when the user selects a contextual data item from a Type/Filter?

Another rule is that the look and feel of web-parts and the way that they interact should be consistent. This benefits not only rapid development, in that UX code may be developed once and re-used for varying functions but also significantly reduces testing and training time.

Universal enterprise UX – Part 2 (Core Web-parts)

The first post on this topic generated several requests for a UX design of the concept and some suggestions that it simply would not be implementable. Following posts on this topic will attempt to deliver at least a high level design so this question can be debated. We will use specific terms e.g. web-part but the design will be generic and not tied to any particular portal technology. We will also use the scenario of a standard order processing system to bring it to life but it could just as well be any application.

Each portal page will comprise a maximum of one large area (web-part) for the display and update of data (the Display/Update web-part). This will present data/allow updates (if the user has the requisite authority etc.). A page could be comprised of several other web-parts (without a Display/Update web-part) but it will never have more than one Display/Update web-part as the scope of the page would then be too confusing for the user. Optionally, this web-part will invoke actions; for example, “New customer entry” or “Add contact to enquiry”. As such it may be described as a “big, dumb” area of the page in that it has no filter, selection (of types) or browsing capability. It exists for displaying and updating data – CRUD operations.

The Display/Update web-part must then be controlled (and contextualized) through other web-parts e.g. filtering, selection (of types) and browsing. These functions may be combined in several different ways to create the web-parts described in the earlier post.

Data with a rich-hierarchy such as Products lend themselves to a browse metaphor and data which is mainly sequential such as Tasks lend themselves to a list metaphor. Our model will implement these as such. There are also a couple other ancillary functions; namely Next (for moving through peers in a hierarchy) and Filtering (for selecting what is in the list) functionality respectively.

Now that we have defined the core functions, several options for combining them into web-parts are possible:

The “Next” functionality simply finds the first match and allows the user to “hop” through matches to whatever filters are set in the Type/Filter web-part.



1) Multiple Filter web-parts. Easier for multiple developers to code, for example; they can each be given a web-part describing a “type” of information e.g. Developer X is responsible for creating a web-part to select “Geography” and Developer Y is responsible for building a web-part to identify a “Category” for successive editing. Issues with code-reuse, consistency and the amount of screen real-estate required.
2) Combined Type and Filter web-parts. Here, the same web-part is used to display all types of data, for example; a drop-down will allow the selection of “Classification” as a type and the user would use filter functionality to select whether “Geography” or “Category” would be displayed in the same web-part as a list. The user would then choose one at a time to display or update in the Display/Update web-part. The user will use the filter capability in the controlling Type/Filter web-part to select the first in the list of matches and then use the Next button to move through matches.
3) Separate Type and Filter web-parts. As above, but the type functionality in the drop-down is taken out of the controlling web-part and placed into a dedicated Type web-part. The issue here is that it may be confusing for the user in that they have to know which web-part is actually controlling the Display/Update web-part i.e. Type or Filter.
4) Combined Type/Filter and Browse/Next web-parts. As with Option 2 but the additional Browse web-part functionality is also included. This option has the advantage of being very flexible in terms of user interaction. It suffers however from a compromise around consistency i.e. The Type/Filter/Browse web-part is used for all controlling functionality (even for those areas that do not need it or it could be potentially confusing e.g. Task list) or we selectively use it for areas that may benefit from browsing either by a list or a hierarchy e.g. Classification.

Option 2 is selected for our model as it is a combination of usability and judicious screen utilization and affords a consistent UX. It also does not result in extraneous functionality being deployed e.g. around the Task example described above.

Our model now has three core web-parts; Display/Update, Browse/Next and Type/Filter. Together, these will enable us to build most applications. They are effectively UX classes; used to build the physical web-parts of the application e.g. both a Product browser and an Order browser can be made from (differently configured) Browse/Next web-parts.

Universal enterprise UX - Part 1 (Concept)

(Originally posted 6 November 2008).

From a UX perspective, portals are a great way of centralising; personalising and publishing the various functions that a user needs to undertake operationally. They are ideal for combining both structured and unstructured data and contextualising between the two. We’re all essentially information workers and users do similar information-centric operations during their day e.g. browsing, analysing, contextualising, starting new events (based upon old events) and data entry. There should be the same UX available for them to do these actions. Not just a similar portal but the same (configurable) web parts.

Where are these gadgets? SAP has a clear concept of UX reuse that plays partly in this space but where are they for other platforms? There are a finite dozen or so UX interactions (Find, Alert, Link, Flag, Copy, Browse, Cascade, CRUD, Audit, Confirm, Search and Analyse) that can be mapped to six or less web parts. Two of these web parts would account for most UX interactions i.e. Web part 1 (Find, Alert, Link, Flag and Copy) and Web part 2 (Browse and Cascade). Web part 1 would mainly deal with lists and Web part 2 would mainly deal with hierarchies.

These could be mix and matched with social networking and content management web parts. That’s just six or so interrelated web parts that could handle the majority of bespoke operational applications today. For example, an order processing system user would be able to search for a particular user, see all their past orders (and correspondence), analyse their propensity to cross/up-sell and take or query their order and flag particular customers for a follow-up call. When the IT department roll-on new functions e.g. recording user feedback at POS, users will know how they work as the web parts would behave the same as existing functions. For the back office, ongoing development, training and testing of incremental functionality would be reduced. MOSS is already treated seriously as an application development platform (http://www.andrewconnell.com/blog/archive/2007/09/24/6116.aspx) as it handles the plumbing every application needs. Some organisations have worked on solutions where they have deployed a similar concept for customers (reusing the same web parts each time) but this approach only really pays dividends with incremental development or new solutions that use the same UX web parts. Why is the universal enterprise UX not more prevalent (?).