Siva R Vaka: Security Related

Showing posts with label Security Related. Show all posts

DOJO Templates parsing is failed because of WebSeal Junction Cookie

PROBLEM: DOJO failed to load the page , i.e. failed to parse the template

REASON: we have dojo templates name " sometemplate-name.html " and webseal junction that we use have junction cookie enabled (created junction with -j option)

Webseal is adding following (junction cookie in the script block) to all .html pages, caused DOJO widget templates also got this script block added at end and failed to parse the template.

SCRIPT language="JavaScript">

<!--

document.cookie = "IV_JCT=%2Ftestjunct1; path=/";

//-->

</SCRIPT>

Solution : Simplest solution we tried is rename the template file name to "sometemplate-name.txt" (used ".txt" instead of the ".html")

WebSeal Junctions - URL Rewriting

Following article explains the different URL rewriting mechanisms in webseal junctions enabled environment. ( Extracted this information from white paper that I came across recently)

Ideally, links in web pages protected by WebSEAL should be relative links. However, WebSEAL is usually deployed in situations where the back-end server is not under the control of the same group.

1. Link Types

a. Relative

b. Server-Relative

c. Absolute

2. Outbound Links Modification

a. Links in HTML

b. Links in Script

3. Inbound links Modification

1. In-bound Server Relative Links

a. Junction Cookies

b. HTTP Referrer Header

c. Transparent Path Junctions

d. Junction Mapping Table

2. In-bound Absolute Links and Virtual host junctions

Link Types

1. Relative

Relative links do not contain the name of the server or the name of the current directory. When the browser receives a relative link, the link appears to be located on the WebSEAL server. Relative links are correctly interpreted as links to other pages in the same directory on the same server.

For example, assume that this line appears in http://serverA/index.html:

<a href=”about.html”>About this site</a>

The browser retrieved this page from https://webseal/Junction1/index.html. This URL is correctly interpreted as pointing to https://webseal/Junction1/about.html. This request would go back to WebSEAL and WebSEAL would know to request http://serverA/about.html.

2. Server-Relative

Server-relative links do not contain the name of the server, but they do contain the name of the directory.

For example, assume that this line appears in http://serverA/index.html:

<a href=”/contact.html”>Contact information</a>

The browser retrieved this page from https://webseal/Junction1/index.html. This URL is interpreted as pointing to /contact.html on the same server.However, from the browser’s perspective the server is WebSEAL. If WebSEAL did not change the HTML, the browser would attempt to retrieve https://webseal/contact.html instead of the correct URL, which is https://webseal/Junction1/contact.html.

3. Absolute

Absolute links contain the name of the server and the directory.

For example, assume that this line appears in http://serverA/index.html:

<a href=”http://ServerA/copyright.html”>Copyright Information</a>

If WebSEAL did not change the HTML, the browser would attempt to connect directly to ServerA, bypassing WebSEAL. A correctly configured firewall would only allow connections to ServerA from WebSEAL.

Out-Bound Links Modification

server-relative and absolute links cannot work without changes

1. Links in HTML

a. Server-relative links are modified to include the current junction name.

b. Absolute links might or might not need modification. Only links to WebSEAL protected resources must be modified. WebSEAL changes the links to protected resources into server-relative links (by default) and adds the proper junction name. If the links are for external sites, WebSEAL does not change them.

The following example shows a fragment of an HTML page from a back-end server:

<A HREF=”about.html”>About this site</A></BR>

<A HREF=”/contact.html”>Contact information</A></BR>

<A HREF=”http://ServerA/copyright.html”>Copyright information</A></BR>

WebSEAL changes the links so that the browser receives this version:

<A HREF=”about.html”>About this site</A></BR>

<A HREF=”/Junction1/contact.html”>Contact information</A></BR>

<A HREF=”/Junction1/copyright.html”>Copyright information</A></BR>

2. Links in Script

This works only for absolute URLs (http[s]://<host name>/<path> , where the host name is a server in a junction) , but it might not work in every case. Consider the following HTML coming from the back end:

<!--

document.write(“<A HREF=/bad.html>This will fail</A></BR>”);

var path = “ServerA/bad.html”;

document.write(“<A HREF=http://” + path + “>Link</A></BR>”);

document.write(“Go to http://ServerA/fun.html</BR>”);

// -->

</SCRIPT>

WebSEAL will modify this HTML and send the following HTML to the browser:

<!--

document.write(“<A HREF=/bad.html>This will fail</A></BR>”);

var path = “ServerA/bad.html”;

document.write(“<A HREF=http://” + path + “>Link</A></BR>”);

document.write(“Go to /Junction1/fun.html</BR>”);

// -->

</SCRIPT>

The first link will not be modified because it is server-relative. The second link, http://ServerA/bad.html, will also not be modified because WebSEAL will not be able to identify that it is a link. The string http://ServerA/fun.html will be modified even though it is not a link.

NOTE: Enabling script filtering

1. Modify the WebSEAL instance configuration file. The [script-filtering] stanza must contain this line:

script-filter = yes

2. Restart WebSEAL:

pdweb restart

3. Create a junction with the junction cookie enabled (-j from the command line).

In-Bound Links Modification

1. In-bound Server Relative links

a. Junction cookie

If a junction is created with the -j option (enable junction cookie), WebSEAL adds JavaScript to every HTML page to include a cookie that contains the junction. When the browser requests another page from the same server, it sends back the cookie with the HTTP request

The HTML source that WebSEAL sends to the browser starts with code such as:

<!--

document.cookie = “IV_JCT=%2FJunction2; path=/”;

//-->

</SCRIPT>

Using JavaScript, this code segment specifies that the cookie IV_JCT will be sent with any request for a page on this server that starts with a slash (/). This method fails in some cases. For example:

a. If you keep a local copy of the page and click a link after the cookie expires,WebSEAL cannot direct the request. A different window or tab could overwrite the cookie if you perform the following steps:

1. Open a page using a junction that has junction cookies enabled, The junction cookie is set to Jct1.

https://<webseal>/Jct1/index.html

2. In the same browser, open another window for a different junction on the same WebSEAL server, which also has junction cookies enabled, The junction cookie is set to Jct2.

https://<webseal>/Jct2/page1.html

3. When you return to the original window and click a link, for example to /page2.html, the cookie is set to Jct2. WebSEAL will attempt to retrieve /page2.html from the server for that junction, instead of Jct1.

b. WebSEAL adds JavaScript to any page that the back-end server reports to be oftype text/html. If the back-end server erroneously reports as HTML pages that are not HTML, WebSEAL adds JavaScript where it is not appropriate.

b. HTTP referrer header

Referer headers rely on the browser to send them out. Browsers do not always send referer

headers.

Sample Request

GET /page2.html HTTP/1.1

host: webseal

referer: https://webseal/Junction1/index.html

because the browser sent the referer header to WebSEAL, WebSEAL interprets the request as https://webseal/

Junction1/page2.html and directs it to the correct back-end server

c. Transparent Path junctions

A transparent path junction has the same name as a directory on the back-end server. If different Web servers use different directories, you can use those directories as junctions. WebSEAL does not change directory names in this scenario, server-relative links require no modification

Use the -x option to create the junctions:

s t <webseal server> create -t tcp -h backend1 -x /app1

s t <webseal server> create -t tcp -h backend2 -x /app2

d. Junction Mapping Table

The junction mapping table is a text file that contains junctions and regular expressions. When WebSEAL looks for a junction, it tries to find which regular expression in the table matches.

Sample

/win *.asp

/win *.htm

/junction1 /wps/myportal/*

The junction mapping table is located in /opt/pdweb/www-default/lib/jmt.conf by default. This file name is specified in the instance configuration file and can be modified as needed.

After you modify the junction mapping table, issue the following pdadmin command:

s t <webseal server> jmt load

2. In-bound absolute links and virtual host junctions

These are junctions that WebSEAL identifies using the host: HTTP header, instead of using a directory name. With virtual host junctions, multiple host names (for example, www.brand1.com and www.brand2.com) resolve to the IP address for WebSEAL

When WebSEAL receives the request, the HTTP header contains a host: field that corresponds to the host part of the URL. For example, if the browser tried to retrieve

https://www.brand1.com/page1.html, the HTTP request would look like the following

example:

GET /page1.html HTTP/1.1

...

host: www.brand1.com

With this method, WebSEAL can receive absolute links and then deal with them correctly

References:

http://www.redbooks.ibm.com%2Fredpapers%2Fpdfs%2Fredp4621.pdf

http://www.redbooks.ibm.com/abstracts/sg246014.html

Enable out of the box WCM Search in the authoring portlet

Recently we had scenario where search functionality in the authoring portlet is not working (i.e. out of the box search that’s available in the authoring portlet).

Even though we had federated search configured to pull the contents from the WCM , Content Authors still need to search for their draft contents,…etc.

Change the following configuration in icm.properties file under

/opt/ibm/WebSphere/wp_profile/PortalServer/jcr/lib/com/ibm/icm

jcr.textsearch.enabled=true

Resources

http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14410670

WCM Security Details - WCM7 - Part3

In Contd. Part 1 and Part 2,

WCM Inline Authoring tools security

1. Inline authoring requires users have access to both the “Item Type” at library level and individual item

2. Example: to edit the current content , you need ‘edit’ access to the ‘Content’ Item Type within the library where the content resides plus edit access to the actual item

3. Read access to authoring tool component itself

Note: you should have at least “privileged user” permission on the reserved authoring portlet page because when you click inline authoring tools it opens up reserved authoring portlet

Personalization Workspace security

1. As explained in WCM Security Part 2 setting at the “access on root” from webcontent libraries portlet will give access to all WCM libraries (Because all wcm libraries are organized in a hierarchy with a common root ).

2. But important thing is WCM libraries common root inherits the access permissions from the “personalization workspace” access settings as shown in above diagram. Unless you block propagation at the personalization workspace level , all access permissions flow throw the WCM libraries.

3. You can set the permission for personalization workspace as shown below ( applicationsàcontentàpersonalizationàbusiness rulesàselect workspaceàextra actionsàedit access)

Resources

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/inline-authoring-with-web-content-management

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Resources_wp7

WCM Security Details - WCM7 - Part2

WCM Security Settings

Section	Details
User defined	If the item is not participating in a workflow, the user can edit the access under user-defined.
Workflow	If an item is participating in a workflow, then the user-defined option does not appear, and the workflow settings are displayed. This cannot be edited. Workflow-defined access is set in workflow stages. NOTE: Published items and workflow-defined item security: If you grant a user editor access to an item in a workflow stage that uses a publish action, then those users are able to edit the published item directly. No draft is created. The same is true for administrator defined security when applied to published items. If you grant a user manager access to an item in a workflow stage that uses a publish action, then those users are able to edit and delete the published item directly. No draft is created. The same is true for administrator defined security when applied to published items. If you grant a user approve access to an item in a workflow stage that uses a publish action, then those users are able to create drafts of the published item.
Administrator defined	Administrators can edit user access to an item at any time by changing the administrator defined settings.
Inheritance	You can also choose to inherit access assigned in the current Web content library, or from an item's parent. Inheritance for all user roles is enabled by default.

NOTES:

1. Security at the Library level, determines who can access the library

2. Security at the Library Resources Level (i.e.components, content, authoring template…etc.) determines what they can see and what functions (read, edit, delete, purge , etc) they can do.

3. User or group who have access to create the content should be able to do New->Content for the library to initially create the content. Then, depending on how the workflow is set up for the content, that user may or may not be able to edit the content because they may not included in the access control for the next workflow stage the content moves to.

4. Element level Security :

a. Content Elements inherit the permissions from the content resource type.

b. In WCM, it is possible to filter who see a content element. To set permissions, go to the default content settings, expand the content element, and click Select editors or Select viewers. Content Elements inherit the permissions from the content resource type.

5. Create new item : The ability to create new items is set at the library level, not item level. You must have at least contributor access to a library and editor access to an item-type to create a new item. If you have access to create any item type, you can also create folders and projects.

6. Security Inheritance

i. Inheritance from a library is based on the role assigned to the overall library, not on the role assigned to specific item types. For example, you may not have access to the presentation template view on a library, but if you inherit the role of editor to a presentation template, you will be able to view and edit that presentation template from the All Items view

ii. Inheritance does not apply to draft items

7. Disabling inheritance :

i. By default, each role's access is automatically inherited down to each item in a library. To prevent a user or group from automatically having inherited access to an item, you will need to turn off inheritance on that item.

ii. Note: By default, inheritance is enabled for all roles and items. To disable automatic inheritance, edit the WCMConfigService.properties file located in the /PortalServer/wcm/shared/app/config/wcmservices/ directory.

iii. To disable automatic inheritance, set this value to “false”: default.inherit.permissions.enabled=false

iv. You will need to restart WebSphere Portal to enable any configuration changes made to this file

8. Work-Flow Security

i. A workflow in WCM is a process that is used to control item state and security

ii. Workflow stages determine the content security for a particular stage. (Do not confuse this with the security of the stage itself).

iii. Setting approve access is only available through the workflow stage

iv. A WCM "non-workflowed" item has only one state, which is published . A nonworkflowed item is represented by a gray icon close to the item.

v. In Draft workflow stage add the “group A” as editors on the content , so when all contents entered into this stage they automatically give access to that group.

vi. Any changes to security in workflow stage doesn’t apply to already draft content until force the content to re enter the draft stage again.

vii. If the content is in the Draft stage, and user who is moving the object (click on next stage) to approve stage should have read access on the approve stage itself. Otherwise it will throw an unauthorized exception.

viii. Similarly authors will need 'approve' access on the 'draft' workflow stage to approve the content by themselves (to move to publish action).

ix. Authors can only add Read access to items after they are published, using the Additional Viewers when published button

9. Batch-editing access controls : An administrator can apply access control settings for multiple items. To batch-edit security:

a. Open an item view.

b. Select the items you would like to batch-edit, and then click More Actions > Edit Access.

c. If you are assigning access to individual users or groups, edit the list of users or groups you would like to set security levels for.

i. To remove items, first select the required items from the item list, then click Remove

ii. To add items, click Add Search for and then select the users or groups you would like to add Security for. Click OK.

d. Select how to apply the new access levels:

i. The same access level changes the access level of the selected users or groups to the specific access level selected in step 5.

ii. Minimum access level changes the minimum access level of the selected users or groups to the access level selected in step 5. The access levels of a user can be raised, but not reduced.

iii. Maximum access level changes the maximum access level of the selected users or groups to the access level selected in step 5. The access levels of a user can be reduced, but not raised.

e. Select an access level.

f. Select inheritance options as required. If you select "ignore", no changes are applied to inheritance.

g. Select to apply these settings either to the Administrator Defined or User Defined access control settings.

h. Select Only change access for existing users or groups. Do not add any new users or groups to change the access level of users and groups have already been granted access to an item. No new users or groups are added.

i. Click OK to finish.

10. Disabling inheritance :

v. By default, each role's access is automatically inherited down to each item in a library. To prevent a user or group from automatically having inherited access to an item, you will need to turn off inheritance on that item.

vi. Note: By default, inheritance is enabled for all roles and items. To disable automatic inheritance, edit the WCMConfigService.properties file located in the /PortalServer/wcm/shared/app/config/wcmservices/ directory.

vii. To disable automatic inheritance, set this value to “false”: default.inherit.permissions.enabled=false

viii. You will need to restart WebSphere Portal to enable any configuration changes made to this file

11. WCM Virtual Users/Groups

a. Author

b. Owner

c. Creator

d. Anonymous Portal users

e. All Authenticated Portal Users

f. All Portal User Groups

g. All Users

Resources

https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14269897&#14269897