Statement of Work No. 2 under the Technical Collaboration Agreement, between Microsoft Corporation and the Registrant, effective as of September 30, 2008

EX-10.65 14 dex1065.htm STATEMENT OF WORK NO. 2 UNDER THE TECHNICAL COLLABORATION AGREEMENT Statement of Work No. 2 under the Technical Collaboration Agreement

Exhibit 10.65

Confidential treatment has been requested for portions of this exhibit. The copy filed herewith omits the information subject to the confidentiality requested. Omissions are designated as [***]. A complete version of this exhibit has been filed separately with the United States Securities and Exchange Commission.

Statement of Work No.2

This SOW2 is entered into by and between Microsoft and Novell on the SOW2 Effective Date under the TCA.

 

  1. PROJECT TITLE AND DESCRIPTION

 

  (a) Title. Directory and Identity Interoperability

 

  (b) Description. In this Additional Project, Novell will provide interoperability between the Current ADFS and Access Manager via WS-Federation, and between the Current WCS and the Novell Products via ISIPvl.0.

 

  2. DEFINITIONS

 

  (a) “Microsoft” means Microsoft Corporation.

 

  (b) “Novell” means Novell, Inc.

 

  (c) “Additional Project” is defined in section 5.5 of the TCA.

 

  (d) “TCA” means the Technical Collaboration Agreement between the parties with an effective date as of November 2, 2006.

(e)

 

  (f) “Current” means as of the SOW2 Effective Date.

 

  (g) “SOW2” means this Statement of Work No. 2.

 

  (h) “SOW2 Effective Date” means the first date by which both Parties have executed this SOW2.

 

  (i) “ADFS” means the Microsoft Active Directory Federation Services component of Windows Server 2003 R2.

 

  (j) “Access Manager” means a new version of, or update to a prior version of, Novell’s Access Manager product.

 

  (k) “WS-Federation” means, with respect to the WS-Federation specification identified at http://www.microsoft.com/interop/osp/default.mspx as it existed on October 16, 2006 and any version of the specification resulting from further standardization efforts identified at http:www.oasis-open.org, the required portions of the specification that are described in detail and not merely referenced therein, as well as the required elements of optional portions of the specification. “WCS” means Microsoft Windows CardSpace.

 

  (l) “Novell Products” and its variations means Access Manager and three (3) Selectors.

 

  (m) “Selector” and its variations means an information card selector reference implementation that implements ISIPv1.0.

 

  (n) “ISIPv1.0” means, with respect to the Identity Selector Interoperability Profile v1.0 specification identified at http://www.microsoft.com/interop/osp/default.mspx as it existed on October 16, 2006 and any version of the specification resulting from further standardization efforts, the required portions of the specification that are described in detail and not merely referenced therein, as well as the required elements of optional portions of the specification. “Acceptance Plan” means acceptance criteria for each of the Deliverables as described in Exhibit A.

 

[*** Confidential Treatment Requested]

Page 1 of 6

 

  (o) “Deliverables” means:

 

  i. Access Manager interoperating via WS-Federation With Current ADFS and via ISIPvl.0 with Current WCS, all as set forth in the Acceptance Plan, with a beta or final version delivered by October 31, 2008.

 

  ii.

First, Second, and Third Selectors, accessible via C++, C”, and Java bindings, respectively, and interoperating via ISIPv1.0 with Current WCS, all as set forth in the Acceptance Plan, at least one of which is available for openSUSE 10.3, at least one of which is available for SUSE Linux Enterprise Server 10, at least one of which is available for Mac OS X, at least one of which is available to Firefox via a Plugin, and at least one of which is available to Safari via a Plugin, with the Selectors delivered by October 31, 2008.

 

  iii. The Firefox and Safari Plugins referenced above, delivered by [October 31,2008].

 

  (p) “STS” means Security Token Service.

 

  (q) “Mac OS X” means Mac OS X version 10.5, known as “leopard”.

 

  (r) “Firefox” means Firefox 2.

 

  (s) “Safari” means Safari 3.

 

  (t) “Plugin” means a plug-in, add-in, add-on, or extension.

 

  (u) “Deliverables Acceptance Date” means the first date by which Microsoft has, or is deemed to have, accepted all the Deliverables.

 

  (v) “Subcontractor” means a third party with whom Novell contracts on a work made for hire basis to meet Novell’s obligations under this SOW2 on Novell’s behalf.

 

  3. PARTIES’ OBLIGATIONS

 

  (a) Novell Obligations.

 

  i. Provide interoperability for the Novell Products with Current WCS via ISIPv1.0 and for Access Manager with the Current ADFS via WS-Federation, all as set forth in the Acceptance Plan.

 

  ii. Make available, at a time and in a manner determined by Novell, the Novell Products.

 

  iii. Demonstrate the Novell Products at one industry event to be mutually agreed upon between the parties and to occur after the SOW2 Effective Date.

 

  iv. Publish, in connection with three Selectors, test scripts and test results from testing the Selectors against the Access Manager STS or the Higgins Project STS pursuant to the Acceptance Plan.

 

  v. Deliver to Microsoft for review and acceptance or rejection according to the Acceptance Plan the Deliverables.

 

  vi. Within twenty-one (21) days following the SOW2 Effective Date, use reasonable commercial efforts to perform and demonstrate the uses cases set forth in section 3 of the Acceptance Plan, substituting the Active Directory Federation Services component of Windows Server 2008 in place of ADFS.

 

  (b) Microsoft Obligations.

 

  i. Review and accept or reject the Deliverables according to the Acceptance Plan.

 

  ii. Pay Novell as described below.

 

  iii. Provide, on an ongoing basis for the term of this SOW2, information reasonably requested by Novell to complete the work described herein.

 

  iv. Demonstrate the interoperability of Microsoft products with the Novell Products at the one industry event mutually agreed upon between the parties and occurring after the SOW2 Effective Date, as referenced above.

 

  4. FEES

 

  (a) The cost incurred by Novell under this SOW2 is agreed by the parties to be [***] (“Fees”).

 

[*** Confidential Treatment Requested]

Page 2 of 6

  (b) The Fees shall be invoiced according to the following milestone schedule:

 

  i. [***]

 

  ii. [***]

 

  (c) In both parties’ judgment, only [***] identified in Section 3.4(e) of the TCA is needed for the Optimization Innovation Laboratory. The parties mutually agree that, pursuant to Section 5.5(e) of the TCA, [***] from Section 3.4(e) of the TCA [***] shall be applied to another TCA objective, namely, Additional Projects under Section 5.5 of the TCA. The parties further mutually agree that as a result of such application, [***]. For clarity, payment of the Fees by Microsoft under this SOW2 [***] of the TCA for Additional Projects.

 

  5. ACCEPTANCE

 

  (a) Each Deliverable shall be accepted by Microsoft provided that such Deliverable meets the applicable acceptance criteria set forth in the Acceptance Plan.

 

  6. TERM

 

  (a) The term of this SOW2 shall commence on the date on which Novell begins to perform the work, and shall end upon the later of Novell’s receipt of all Fees under the Fees Section above and 90 days after the Deliverables Acceptance Date; provided however that sections 3.a.ii, 3.a.iii and 3.b.iv shall survive the term of this SOW2.

 

  (b) Under no circumstance will termination or expiration of this SOW2 result in termination or expiration of the TCA.

 

  7. OTHER

 

  (a) Novell has no obligation under this SOW2 to support or maintain the Novell Products.

 

  (b) [intentionally omitted]

 

  (c) Novell may contract with a Subcontractor on terms requiring the Subcontractor to comply with the applicable terms of this SOW2 and the TCA.

 

  (d) This SOW2 does not change the ownership of anything created, developed, provided, delivered, published, made available, or demonstrated hereunder, and under no circumstances are the Deliverables hereunder works made for hire.

 

  (e) This SOW2 may be terminated by either party in the event that the other party has materially breached any term of this SOW2 upon receipt of written notice thereof if the nonperformance or breach is incapable of cure, or upon the expiration of ten (10) days (or such additional cure period as the non-defaulting party may authorize) after receipt of written notice thereof if the nonperformance or breach is capable of cure and has not been cured.

 

  (f) [***]. In addition, Novell may propose additional work deemed relevant to this Additional Project, and such work may be added to this SOW2 upon the mutual written consent of the parties.

 

  Novell, Inc.       Microsoft Corporation
By:  

/s/ Jeff Jaffe

     By:  

/s/ William Laing

Name:  

Jeff Jaffe

     Name:  

William Laing

Title:  

CTO & EVP

     Title:  

CVP

Date:  

9/28/08

     Date:  

9/30/08

 

[*** Confidential Treatment Requested]

Page 3 of 6

Exhibit A

Acceptance Plan

 

1. Overview. This Acceptance Plan contains acceptance criteria for each of the Deliverables In SOW2. The criteria for Access Manager are set forth in section 3 hereof, and the criteria for the Selectors are set forth in section 4 hereof, and Microsoft’s obligation to accept a Deliverable shall be contingent upon the Deliverable meeting the criteria prescribed herein.

 

2. Acceptance. Deliverables will be deemed satisfactory to and accepted by Microsoft unless within thirty (30) days after delivery, Microsoft gives Novell written notice of aspects in which a Deliverable does not meet the SOW2 requirements. Upon receipt of such written notice, Novell will use commercially reasonable efforts to make such changes as will be required to correct any deficiencies.

 

3. Acceptance Criteria: Access Manager. Either via a face to-face meeting or an application sharing collaboration meeting over the Internet, the following use cases will be demonstrated.

 

  3.1 Use Case One (WCS): NIDP (Novell Identity Provider) acting as a relying party. In Use Case One, a user has a personal card and would like to use that card to login to a system. The basic steps are:

 

  3.1.1 The user requests access to a protected resource that requires a WCS Authentication contract at the access gateway.

 

  3.1.2 The user is redirected to the NIDP for login.

 

  3.1.3 The NIDP requests a card from the user.

 

  3.1.4 A Selector prompts the user for which card to use, and the user picks a personal card.

 

  3.1.5 If this is the first time the NIDP has seen this card, then the following are performed:

 

  3.1.5.1   The user is prompted for his or her username and password.

 

  3.1.5.2   The username and password are verified against a user store.

 

  3.1.5.3   The card information is saved in a trust store.

 

  3.1.6 It this is not the first time the NIDP has seen this card, then the card is looked up in the trust store and the user is redirected back to the access gateway.

 

  3.1.7 The access gateway then uses any identity injection, authorization, or form fill policy with information either from the personal card or from the user store.

 

  3.1.8 The user is allowed access to the protected resource.

 

  3.2 Use Case Two (WCS): NIDP acting as an identity provider. In Use Case Two, a user has a managed card issued from an identity provider, and a relying party is requesting that this card be used for authentication. The basic steps are:

 

  3.2.1 The user requests access to a protected resource that requires a WCS Authentication contract at the access gateway.

 

  3.2.2 The user is redirected to the NIDP for login.

 

  3.2.3 The relying party requests a managed card from the NIDP.

 

  3.2.4 A Selector presents the user with a list of managed cards that will satisfy this request, prompts the user for which card to use, and the user picks a card.

 

  3.2.5 The Selector makes a request to the identity provider for authentication.

 

  3.2.6 The username and password for the identity provider is requested.

 

  3.2.7 The information from the managed card is given to the Selector, which passes it on to tile relying party.

 

  3.2.8 The user is then authenticated based on the trust associated between the identity provider and the relying party.

 

[*** Confidential Treatment Requested]

Page 4 of 6

  3.2.9 The access gateway then uses the information on the managed card or from a federated user store to get information for Access Manager policies.

 

  3.3 Use Case Three (WCS): NIDP acting as a card issuer. In Use Case Three, an NIDP will be issuing a managed card to a user that can either be backed by a username/password, or a personal card. The basic steps are:

 

  3.3.1 The user logs into the NIDP.

 

  3.3.2 The user goes to a page on the NIDP’s portal.

 

  3.3.3 The user requests the creation of a managed card.

 

  3.3.4 The user is asked if he or she wants to back the managed card with a personal card.

 

  3.3.5 If the user chooses to back the managed card with a personal card:

 

  3.3.5.1   The NIDP requests the personal card.

 

  3.3.5.2   A Selector asks the user to select the personal card, or to create a new personal card.

 

  3.3.5.3   The Selector sends the selected or created personal card to the NIDP.

 

  3.3.6 The user is given a managed card.

 

  3.4 Use Case Four (ADFS): NIDP providing authentication to a resource protected by Active Directory Federation Services. In Use Case Four, a user needs access to a resource that is protected by Active Directory Federation Services. The basic steps are:

 

  3.4.1 The user requests access to the resource.

 

  3.4.2 The resource asks for authentication by Active Directory Federation Services.

 

  3.4.3 An Active Directory Federation Services server is setup to know about an NIDP and gives the user the option of logging in at the NIDP.

 

  3.4.4 The user logs into the NIDP and is provided a token that is sent to the Active Directory Federation Services server and satisfies the request of the resource.

 

  3.4.5 The user is allowed to access the resource.

 

  3.5 Use Case Five (ADFS): Active Directory Federation Services providing authentication to a resource protected by NIDP. In Use Case Five, a user needs access to a resource that is protected by NIDP. The basic steps are the same as Use Case 4 with AD FS and NIDP switching places.

 

4. Acceptance Criteria: Selectors. The following will be demonstrated for the Selectors:

 

  4.1 Source Code. A reference to source code for:

 

  4.1.1

A Selector available for openSUSE 10.3 interoperating via ISIPv1.0 with the GetToken functionality of Current WCS and accessible via C++ bindings.

 

  4.1.2

A Selector available for Mac OS X interoperating via ISIPv1.0 with the GetToken functionality of Current WCS and accessible via C-+ bindings.

 

  4.1.3 A Selector for openSUSE 10.3 and SUSE Linux Enterprise Server 10 interoperating via ISIPvl.0 with the GetToken functionality of Current WCS.

 

  4.1.4 A Selector available for Linux interoperating via ISIPv1.0 with the GetToken functionality of Current WCS and accessible via Java bindings.

 

  4.1.5

A Selector available for Linux interoperating via ISIPvl.0 with the GetToken functionality of Current WCS and accessible via C# bindings.

 

  4.2 Interoperability. Either via a face-to-face meeting or an application-sharing collaboration meeting over the Internet, interoperability of the Selector Deliverables will be shown using:

 

  4.2.1 The Access Manager STS or the Higgins Project STS.

 

  4.2.2 Access Manager.

 

[*** Confidential Treatment Requested]

Page 5 of 6

  4.2.3 Firefox.

 

  4.2.4 Safari.

 

  4.3 Card Import/Export. Either via a face-to-face meeting or collaboration over the Internet, compatibility of the Selector Deliverables will be shown for card import/export.

 

  4.3.1 Cards exported from WCS are successfully imported into the Novell Selector, and user access to resources with those cards using the Novell Selector is preserved.

 

  4.3.2 Cards exported from the Novell Selector are successfully imported into WCS, and user access to resources with those cards using WCS is preserved.

 

[*** Confidential Treatment Requested]

Page 6 of 6