Consider performing a
Google Summer of Code 2008 : wiki
Project |
Basic Security Profile (BSP) 1.0 Validation for Apache Rampart |
Student |
Heshan Suriyaarachchi |
Blog |
|
Proposal |
http://wiki.apache.org/general/HeshanSuriyaarachchi/GSoC2008/proposal |
Project Title
Basic Security Profile (BSP) 1.0 Validation for Apache Rampart
Abstract
Apache Rampart is the security module of Axis2. It implements Web Service Security, WS-Secure Conversation, WS-Trust and WS-Security Policy specifications. Basic Security Profile 1.0 from web services interoperability organization defines a set of standards that further clarifies the ambiguities in other specifications with details. Even though Apache Rampart adheres to these standards when securing the messages, there is no proper validation done for BSP 1.0 standards in incoming messages. Purpose of this project is to implement a handler in Rampart which validates the incoming messages for BSP 1.0 standards.
Weekly Plans & Progress
Week/Weeks ending on |
Plan |
References |
Progress |
May 30 |
1.Go through BSP(Basic Security Profile) 1.0 Specification |
[1] |
Done |
|
2.Build Rampart |
[2] |
Done |
June 6 |
1.Go through Rampart Documentation |
[3] |
Done |
|
2.Run Rampart Samples |
[4] |
Done |
June 13 |
1.Read web references on Writing a Handler |
[5] [7] |
Done |
|
2.Writing a simple Handler |
[6] |
Done (Encountered some problems. These were discussed in the Rampart Devlist) |
June 27 |
1.Read the article "Understanding WS – Security Policy Language" to understand WS-Security |
[9] |
Done |
|
2.Went through the WS-Security and BSP 1.0 specifications to identify the key features to be implemented |
[8] [1] |
Done |
|
3.Went through the article "Web Services Security with Apache Rampart(Message-Level Security)" and ran the samples given |
[10] [11] |
Done |
July 11 |
1.Do the BSP validation for TimeStamp, UsernameToken and BinarySecurityTokens |
|
Done |
|
2.Create a Jira to upload the completed code for Mid Evaluation |
|
Done |
|
3.Complete the Google Mid Evaluation web app |
|
Done |
July 14 |
Mid Evaluation Deadline |
--- |
--- |
July 28 |
1.Completed validation for the policy in sample01 of the rampart samples |
|
Done |
|| || 2.Completed validation for the policy in sample02 of the rampart samples || || ||
Aug 15 |
1.Completed validation for the policy in sample03 of the rampart samples |
|
|
|| || 2.Completed validation for the policy in sample04 of the rampart samples || || ||
Aug 18 |
1.Submit Final Evaluations to Google |
|
|
Sept 01 |
Final Evaluation Deadline |
--- |
--- |
Features to be implemented
5. SecurityHeaders
5.1 Processing Order
- Web Services Security: SOAP Message Security defines the order for processing elements within wsse:Security headers. The Profile provides the following guidance:
5.1.1 In Order of Appearance
R3212 Any SIGNATURE, ENCRYPTED_KEY, and ENC_REFERENCE_LIST elements MUST be ordered within a SECURITY_HEADER so a receiver will get the correct result by processing the elements in the order they appear.
5.2 SOAP Actor Attribute
5.2.1 Avoid Target Ambiguity
R3206 Any SOAP_HEADER MUST NOT contain more than one SECURITY_HEADER with the actor attribute omitted. R3210 Any SOAP_HEADER MUST NOT contain more than one SECURITY_HEADER with the same actor attribute value.
6. Timestamps
Web Services Security: SOAP Message Security defines a Timestamp element for use in SOAP messages. The Profile places the following constraints on its use:
6.1 Placement
6.1.1 Not More Than One per Security Header
R3227 A SECURITY_HEADER MUST NOT contain more than one TIMESTAMP.
6.2 Content
6.2.1 Exactly One Created per Timestamp
R3203 A TIMESTAMP MUST contain exactly one CREATED.
6.2.2 Not More Than One Expires per Timestamp
R3224 Any TIMESTAMP MUST NOT contain more than one EXPIRES.
6.2.3 Created Precedes Expires in Timestamp
R3221 Any TIMESTAMP containing an EXPIRES MUST contain a CREATED that precedes its sibling EXPIRES.
6.2.4 Timestamp Contains Nothing Other Than Create and Expires
R3222 Any TIMESTAMP MUST NOT contain anything other than CREATED or EXPIRES elements.
6.3 Constraints on Created and Expires
6.3.1 Value Precision to Milliseconds
R3220 Any CREATED SHOULD NOT contain a seconds value with more than three digits to the right of the decimal (milliseconds). R3229 Any EXPIRES SHOULD NOT contain a seconds value with more than three digits to the right of the decimal (milliseconds).
6.3.2 Leap Second Values Prohibited
R3213 Any CREATED containing second values MUST specify seconds values less than 60. R3215 Any EXPIRES containing second values MUST specify seconds values less than 60.
6.3.3 ValueType Attribute Prohibited
R3225 Any CREATED MUST NOT include a ValueType attribute. R3226 Any EXPIRES MUST NOT include a ValueType attribute.
6.3.4 UTC Format Mandatory
R3217 Any CREATED MUST contain time values in UTC format as specified by the XML Schema type (dateTime). R3223 Any EXPIRES MUST contain time values in UTC format as specified by the XML Schema type (dateTime).
7. Security Token References
Web Services Security: SOAP Message Security defines a wsse:SecurityTokenReference element for use in SOAP messages. The Profile places the following constraints on its use:
7.1 Content
7.1.1 Exactly One SecurityTokenReference Child Element
R3061 A SECURITY_TOKEN_REFERENCE MUST provide exactly one token reference.
7.2 Direct References
7.2.1 Direct Reference to Security Token Reference Prohibited
R3057 Any STR_REFERENCE MUST NOT reference a SECURITY_TOKEN_REFERENCE. R3064 Any STR_REFERENCE MUST NOT reference an STR_EMBEDDED.
7.2.2 Reference/@ValueType Attribute Mandatory
R3059 Any STR_REFERENCE MUST specify a ValueType attribute. R3058 Any STR_REFERENCE ValueType attribute MUST contain a value for the referenced SECURITY_TOKEN specified by the corresponding security token profile.
7.2.3 Reference/@URI Attribute Mandatory
R3062 Any STR_REFERENCE MUST specify a URI attribute.
7.3 Key Name References
7.3.1 Key Name References Prohibited
R3027 Any SECURITY_TOKEN_REFERENCE MUST NOT contain an STR_KEY_NAME.
7.4 Key Identifier References
7.4.1 KeyIdentifier/@ValueType Attribute Mandatory
R3054 Any STR_KEY_IDENTIFIER MUST specify a ValueType attribute. R3063 Any STR_KEY_IDENTIFIER ValueType attribute MUST contain a value specified within the security token profile associated with the referenced SECURITY_TOKEN.
7.4.2 KeyIdentifier/@EncodingType Attribute Mandatory
R3070 Any STR_KEY_IDENTIFIER that refers to a SECURITY_TOKEN other than a SAML_TOKEN MUST specify an EncodingType attribute. R3071 Any STR_KEY_IDENTIFIER EncodingType attribute MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".
7.5 Embedded References
7.5.1 Embedded Content
R3060 Any STR_EMBEDDED MUST contain only a single child element which is an INTERNAL_SECURITY_TOKEN.
7.5.2 Embedded Token Format
R3025 Any INTERNAL_SECURITY_TOKEN contained in an STR_EMBEDDED MUST be in the same format as if it were a child of a SECURITY_HEADER.
7.5.3 Security Token Reference in Embedded Prohibited
R3056 Any STR_EMBEDDED MUST NOT contain a wsse:SecurityTokenReference child element.
7.6 Internal References
7.6.1 Direct or Embedded References Where Possible
R3022 Any SECURITY_TOKEN_REFERENCE that references an INTERNAL_SECURITY_TOKEN which has a wsu:Id attribute MUST contain an STR_REFERENCE or STR_EMBEDDED.
7.6.2 Direct Preferred to Embedded References
R3023 Any SECURITY_TOKEN_REFERENCE that references an INTERNAL_SECURITY_TOKEN that is referenced several times SHOULD contain an STR_REFERENCE rather than an STR_EMBEDDED.
7.6.3 Shorthand XPointers Mandatory for Direct References
R5204 Any STR_REFERENCE to an INTERNAL_SECURITY_TOKEN having an ID attribute MUST contain a URI attribute with a Shorthand XPointer value.
7.6.4 Security Tokens Precede Their References
R5205 Any INTERNAL_SECURITY_TOKEN that is not contained in an STR_EMBEDDED MUST precede all SECURITY_TOKEN_REFERENCE elements that reference it in the SOAP_ENVELOPE.
7.6.5 References Between Security Headers Prohibited
R3066 Any STR_REFERENCE that is a descendant of a SECURITY_HEADER MUST NOT use a Shorthand XPointer to refer to an INTERNAL_SECURITY_TOKEN located in a SECURITY_HEADER other than the SECURITY_HEADER that contains the STR_REFERENCE. R3067 Any STR_REFERENCE that is a descendant of an ENCRYPTED_DATA MUST NOT use a Shorthand XPointer to refer to an INTERNAL_SECURITY_TOKEN located in a SECURITY_HEADER other than the SECURITY_HEADER containing a reference (EK_REFERENCE_LIST or an ENC_REFERENCE_LIST) to the ENCRYPTED_DATA.
7.7 External References
7.7.1 Direct References Where Possible
R3024 Any EXTERNAL_TOKEN_REFERENCE that can use an STR_REFERENCE MUST contain an STR_REFERENCE.
7.8 SecurityTokenReference to KeyInfo
7.8.1 Reference to KeyInfo Prohibited
R3211 Any SECURITY_TOKEN_REFERENCE MUST NOT reference a ds:KeyInfo element.
10. Binary Security Tokens
10.1 Binary Security Tokens
10.1.1 BinarySecurityToken/@EncodingType Attribute Mandatory
R3029 Any BINARY_SECURITY_TOKEN MUST specify an EncodingType attribute. R3030 Any BINARY_SECURITY_TOKEN EncodingType attribute MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".
10.1.2 BinarySecurityToken/@ValueType Attribute Mandatory
R3031 Any BINARY_SECURITY_TOKEN MUST specify an ValueType attribute. R3032 Any BINARY_SECURITY_TOKEN ValueType attribute MUST have a value specified by the related security token profile.
11. Username Token
This section of the Basic Security Profile 1.0 incorporates the following specifications by reference:
Web Services Security: UsernameToken Profile 1.0, OASIS Standard 200401, March 2004
Web Services Security: UsernameToken Profile 1.0, Errata 1.0 Committee Draft 200401, September 2004
11.1 Password
11.1.1 Not More Than One Password
R4222 Any USERNAME_TOKEN MUST NOT have more than one PASSWORD.
11.1.2 Password/@Type Attribute Mandatory
R4201 Any PASSWORD MUST specify a Type attribute.
11.1.3 Digest Value
R4212 Any PASSWORD with a Type attribute value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest" MUST have its value computed using the following formula, where "+" indicates concatenation: Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) ). That is, concatenate the text forms of the nonce, creation time, and the password (or shared secret or password equivalent), digest the combination using the SHA-1 hash algorithm, then include the Base64 encoding of that result as the password (digest). Any elements that are not present are simply omitted from the concatenation.
11.1.4 Key Derivation
11.2 Created
11.2.1 Not More Than One Created
R4223 Any USERNAME_TOKEN MUST NOT have more than one CREATED.
11.3 Nonce
11.3.1 Not More Than One Nonce
R4225 Any USERNAME_TOKEN MUST NOT have more than one NONCE.
11.3.2 Nonce/@EncodingType Attribute Mandatory
R4220 Any NONCE MUST specify an EncodingType attribute. R4221 Any NONCE EncodingType attribute MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".
11.4 SecurityTokenReference
11.4.1 UsernameToken Reference/@ValueType Attribute Value
R4214 Any STR_REFERENCE to a USERNAME_TOKEN MUST have a ValueType attribute with a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken".
11.4.2 KeyIdentifier Prohibited
R4215 Any SECURITY_TOKEN_REFERENCE to a USERNAME_TOKEN MUST NOT contain an STR_KEY_IDENTIFIER.
References
[1] - http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
[2] - http://ws.apache.org/rampart/source-repository.html
[3] - http://ws.apache.org/rampart/developer-guide.html
[4] - http://ws.apache.org/rampart/quick-start.html
[5] - http://ws.apache.org/axis2/1_4/Axis2ArchitectureGuide.html#bmSOAPPM
[6] - http://www.developer.com/java/web/article.php/3529321
[8] - http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[9] - http://wso2.org/library/3132