Learn More: WebSphere Core Security FAQ

To disable security, please perform the following steps via wsadmin:

1. /bin/> wsadmin -conntype NONE

2. wsadmin> securityoff

3. wsadmin> exit

4. Restart the servers.

5. Enable the security from the WebSphere Admin Console.

6. Once the needed corrections are made, you can re-enable security in the WebSphere Admin Console and then restart WebSphere.

When the secure flag is enabled for LTPA cookies, you should see the Secure key word at the end of the LTPAToken2 cookie value, e.g.:

LtpaToken2=tzHGA2i0eSFpSKtiFlpb9N6UtPYo74arpre/anjT5yDmbIkOIeCnvuJWUO5Gp 8l4qqNr5/IstokFrPnm1yS8TpZICCYrovuf90zjxAVe+MYTOSLXvAIIfVHRaNKWaPNL6cim4 dtdS3P930kV7iyhPM1QVIoDvWiMBK3ZaM/ChxMguZaSvJ2pF6DnXYU3B+WvXbcWCQeyDRR1Y WiZoMOB2Tktt3YwM+ixvvcPBJDSkWCe9GqsHj1LjelPGFHDc88Y/u1lkeLDPQJpA0CNVX8D6 NxeVAyAPSJoU4PNqarkuXA0vCJD6g1zwa/EqATa+CS8Zb0=; Path=/; Secure

In the WebSphere Admin Console click Security > Global security. Under Authentication, click Web and SIP security > Single sign-on (SSO):
LTPA V2 cookie name
To take advantage of this functionality, a custom property must be set. For LTPA tokens, the custom property com.ibm.websphere.security.customLTPACookieName can be set to any valid string (special characters and spaces are not permitted) for the LTPA token cookie, and com.ibm.websphere.security.customSSOCookieName for the LTPA2 (SSO) token cookie. Each property is case-sensitive. The value for this property is a valid string.

Custom cookie names allow you to logically separate authentication between Single Sign-On (SSO) domains and to enable customized authentication to a particular environment.

The WebSphere Application Server LTPA token expires based on the lifetime of the login session, not based upon activity or inactivity. Thus, the WebSphere Application Server login session will not expire if the user performs no action for some period of time. However, the HTTPSession does expire based upon inactivity.
You can setup single sign-on with SPNEGO to avoid users having to re-login when the LTPA token is expired.
If in your application you need to expire the use of an application based on idleness, you must explicitly code this in your application. You can capture when a user arrives with an expired session (really, a new session) and force them to login again if you think this is necessary. Keep in mind that doing this undermines single sign-on across applications.

Form logout is a mechanism to log out without having to close all Web-browser sessions. After logging out of the form logout mechanism, access to a protected web resource requires re-authentication.
Alternatively, the same can be achieved calling request.logout() method from the servlet 3.0 API. For details see Servlet security methods.

Unless otherwise stated, security custom properties can be set in the WebSphere Admin Console under Security > Global security > Custom properties. Then click New to add a new custom property and its associated value.
See Security custom properties for a list of security custom properties, supporting details and default values.

Monitor Configurator Operator Administrator Iscadmins Deployer Admin Security Manager Auditor

More information on each of these roles can be found in the Administrative roles IBM Docs page.

To set a security custom property using the wsadmin command when your server is running you can use e.g.:

C:\ws\85\appserver\profiles\AppSrv01\bin>wsadmin -lang jython WASX7209I: Connected to process "server1" on node mytestNode01 using SOAP connector; The type of process is: UnManagedProcess C:\ws\85\appserver\profiles\AppSrv01\bin>wsadmin -lang jython WASX7209I: Connected to process "server1" on node mytestNode01 using SOAP connector; The type of process is: UnManagedProcess WASX7031I: For help, enter: "print Help.help()" wsadmin>AdminTask.setAdminActiveSecuritySettings('[-customProperties ["com.ibm.websphere.security.test=false"]]') '' wsadmin>AdminConfig.save() '' wsadmin>exit

If the server is not running you can use the -conntype NONE option like this:

C:\ws\85\appserver\profiles\AppSrv01\bin>wsadmin -lang jython -conntype NONE WASX7357I: By request, this scripting client is not connected to any server process. Certain configuration and application operation s will be available in local mode. WASX7031I: For help, enter: "print Help.help()" wsadmin>AdminTask.setAdminActiveSecuritySettings('[-customProperties ["com.ibm.websphere.security.test=false"]]') '' wsadmin>AdminConfig.save() '' wsadmin>exit

The above wsadmin AdminTask commands will set the custom property if it does not exist or change the value to whatever you specify if the property was already set.

If you prefer to not use AdminTask you could use a script like this:

sec = AdminConfig.getid('/Security:/') prop = AdminConfig.getid('/Cell:/Security:/Property:com.ibm.websphere.security.test/') if prop: AdminConfig.modify(prop, [['value', 'false']]) else: AdminConfig.create('Property', sec, [['name','com.ibm.websphere.security.test'], ['value','false']]) AdminConfig.save()

You could copy those lines into a text editor and save them as customSecurityProp.py in the bin directory of your profile and then run it like this:

C:\ws\85\appserver\profiles\AppSrv01\bin>wsadmin -lang jython -f customSecurityProp.py WASX7209I: Connected to process "server1" on node mytestNode01 using SOAP connector; The type of process is: UnManagedProcess C:\ws\85\appserver\profiles\AppSrv01\bin>

Note: When you change a security custom property it will normally require a complete re-initialization of the security subsystem and that can only be achieved by restarting all of the WebSphere Application Server processes.

To enable security auditing, follow the steps in the How to enable security auditing in WebSphere Application Server IBM Support TV video available in the Video Tutorials section of the Learn more page or the Lab - WebSphere Application Server security auditing (more detailed).
For a list of available auditable events see Auditable security events.
For general information on security auditing, see Auditing the security infrastructure.

The following steps below can be followed to accomplish the change of password using Jython:

1. Start wsadmin from your profile’s bin directory:

WebSphere_root/profiles/profile_name/bin wsadmin -lang jython -user primaryadminuser -password password

2. Then run the following:

AdminTask.changeFileRegistryAccountPassword('[-userId newAcct -password newPassword -uniqueName]')

3. Then run the following:

AdminConfig.save()

4. Restart the application server

Note: If you run WebSphere ND make sure that the node agents are started, otherwise you must do a syncNode later.

For information on custom password encryption see Enabling a plugpoint for custom password encryption.

To enable security auditing, follow the steps in the How to enable security auditing in WebSphere Application Server IBM Support TV video available in the Video Tutorials tab above or the Lab - WebSphere Application Server security auditing (more detailed).
For a list of available auditable events see Auditable security events.
For general information on security auditing, see Auditing the security infrastructure.

Short answer: no, it's not possible.

Long answer: Group memberships are stored within the repositories (fileRegistry.xml, LDAP, DB, etc.) themselves, not on WebSphere. There's no standardized means for a repository to define group members which exist in a different repository. If WebSphere were to have a feature to add users to groups across repositories, it would need to have some proprietary means of defining group memberships externally to the repositories -- WebSphere does not have this. This would not be a good feature as it would break LDAPv3 specification and it would make the administration of the repositories themselves more difficult: most IT departments have separate administrative personnel for their LDAPs, and if their WebSphere admins were going and defining group memberships that were not visible to the LDAP admin, this would cause a lot of confusion.

There is one exception to this rule: certain DB repositories do support ways of defining group members which exist in other repositories. This only works for DBs. This will not work for LDAPs (including Microsoft Active Directory with multiple domains) or the local file registry.

If the DB repository supports members from other repositories, you must specify the repositoriesForGroups parameter to add the unique repository IDs of those repositories to the DB repository. The group configuration for the LDAP repository is ignored when you specify the repositoriesForGroups parameter -- it will only use the DB for group definitions.

For example, if you want the groups in the database repository to accept the members from an LDAP repository, you need to set the configuration parameter repositoriesForGroups of the LDAP repository to the repository ID of the database repository.

For reference for DB-only cross-repository membership please see Configuring the database adapter.

• Both sides (cell 1 and cell 2) must use an IDENTICAL user registry
• Both sides (cell 1 and cell 2) must use the SAME realm name
• Both sides (cell 1 and cell 2) must use the SAME DNS domain
• Both sides (cell 1 and cell 2) must use the SAME LTPA keys

To configure traditional WebSphere for LTPA SSO, please see the following steps:
Step 1 on cell 1: Export the LTPA keys from cell 1

1. Login into the cell 1 WebSphere Admin Console as administrative user.

2. Click Security > Global security > Authentication mechanisms and expiration.

3. Click LTPA. In the Password and Confirm password fields, enter the password that is used to encrypt the LTPA keys. Remember the password so that you can use it later when the keys are imported into the other cell.

4. In the Fully qualified key file name field, specify the fully qualified path to the location where you want the exported LTPA keys to reside. You must have write permission to this file, for example, /tmp/Cell1LTPAExportkey.txt

5. Click Export keys to export the keys and you will see the file under /tmp/Cell1LTPAExportkey.txt. Note: VERY IMPORTANT: DON'T click on Generate keys. Move the Cell1LTPAExportkey.txt to cell 2 and put it in an e.g. C:\LTPA folder.

1. Login into the cell 2 Admin Console as administrative user.

2. Click Security > Global security > Authentication mechanisms and expiration.

3. Click LTPA. In the Password and Confirm password fields, enter the password that is used to decrypt the LTPA keys. This password must match the password that was used in the cell from which you are importing the keys.

4. In the Fully qualified key file name field, specify the fully qualified path to the location where the signer keys reside. You must have write permission to this file, for example C:\LTPA\Cell1LTPAExportkey.txt

5. Click Import keys to import the keys.

6. Click OK, then Save

7. Restart server. Note: VERY IMPORTANT: DON'T click on Generate keys.

After restarting the server, please make sure that the keys are from both cells are the same by exporting the LTPA keys from cell 2 as e.g. CELL2exportLTPA.txt (like you did in step 1 ) and compare that file with the previously exported Cell1LTPAExportkey.txt file.

NB: It is possible to define multiple domain names in the WebSphere configuration, but a given Cookie can only have a single realm on the browser-side. It is this limitation of the Cookie specification which prevents any Cookie-based SSO from working with hosts that are in different DNS domains. All servers in the SSO domain must use the same DNS domain. You can configure the SSO domain name under Security > Global security > Authentication > Web and SIP security > Single sign-on (SSO): Domain name
For further information please see Single sign-on settings.