Sometimes its necessary to implement an SSO-Enviroment over different
WebSphere-Cells (e.g. Production-Cell and Acceptance-Cell). To do this
both cells need the same LTPA-Keys.
The synchronization of LTPA-Keys
can be done over Admin-Console.
1. To Export LTPA-Keys from a
Cell navigate to
Security > Secure
administration, applications, and infrastructure >
Authentication mechanisms and expiration.
2. Fill out
the import/export-Form at the bottom of the page
and click "Export keys". The LTPA-Keys will be exported to the specified
directory. (The Keys will be password protected.)
3. Copy the
exported ltpa.jceks-File to other the Cell (do not override ltpa.jceks
of this cell).
4. Take a look at ltpa.jceks-File of this cell and
note the file-size.
File is located in
/"websphere"/"dmgr"/config/cells/"cellname"/ltpa.jceks
5. To
import the LTPA-Keys to other Cell navigate to
Security > Secure administration, applications, and
infrastructure > Authentication mechanisms
and expiration.
6. Fill out "Cross-cell Single sign on"-From and
click "Import keys"
7. File size of ltpa.jceks-File of this Cell
should now be increased.
Sometimes nothing happens to file size of
ltpa.jceks-File and Cross-cell SSO will not work (WAS-Bug).
In this
case just repeat the import.
8. Restart servers/node
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Thursday, April 1, 2010
Friday, March 12, 2010
Custom User Registry
To enable security in WebSphere Application Server, you need
to logon to WAS admin console. The default URL for accessing WAS admin
console would be http://localhost:9060/admin
in your local machine. When the security is not enabled WAS would ask
you for a username and you can provide any username you want. When
enabling security in WAS 6.0 there are three different types of user
registries available.
1. Custom User Registry
2. LDAP
3. Local OS.
Here I will be talking about enabling security using Custom User Registry as the Active User Registry. The first step in enabling security using Custom user registry is to create one user file and a group file. The group file will be of the following format.
name:gid:users:display name
For eg:
admins:1:admin,admin1:Administrative group
operators:2:operator,operator1:Operators group
users:3:user1,user2,user3,bobby:
The groups file will be saved with name groups.props in directory D:\IBM\security.
Then create a users file using the following format.
name:passwd:uid:gids:display name
admin:admin:10:1:Admin
admin1:admin1:11:1:Admin 1
user:user:12:2,3:User
The users file will be saved with name users.props in directory D:\IBM\security. (This cane be any directory)
The next fist step is to click on Global Security link under security menu.
The security configuration page opens up.
Once the security configuration page got opened click on Custom under user registries section. The custom user registry page opens.
Under general properties enter the server admin username and password you want and click on the custom properties link under Additional properties section. Click on new button in the custom properties page.
Enter groupsFile as the name and D:/IBM/security/groups.props as the value. Save the custom property value and create another custom property and enter usersFile as the name D:/IBM/security/users.props as the value. Save the values you will be returned to the custom properties page. Now the custom properties page would look like the one in the below picture.
Save the changes made and return to the security configuration page.
Now select custom user registry under active user registry and select the ‘Enable global security’ checkbox. Uncheck ‘Enforce Java 2 Security’
Save the changes. Restart your server. Once global security is enabled on the WAS server, we need to provide the admin username and password for starting and stopping the server. The command for starting the server once the security is enabled is
startServer.bat server1 -user admin -password admin
where server1 is the name of your server. If your server is integrated with an IDE like RAD, double click on the server from the server perspective and enter the username and password after selecting ’security is enabled on this server’ checkbox under security section in your server configuration window.
#####################################################################
1. Custom User Registry
2. LDAP
3. Local OS.
Here I will be talking about enabling security using Custom User Registry as the Active User Registry. The first step in enabling security using Custom user registry is to create one user file and a group file. The group file will be of the following format.
name:gid:users:display name
For eg:
admins:1:admin,admin1:Administrative group
operators:2:operator,operator1:Operators group
users:3:user1,user2,user3,bobby:
The groups file will be saved with name groups.props in directory D:\IBM\security.
Then create a users file using the following format.
name:passwd:uid:gids:display name
admin:admin:10:1:Admin
admin1:admin1:11:1:Admin 1
user:user:12:2,3:User
The users file will be saved with name users.props in directory D:\IBM\security. (This cane be any directory)
The next fist step is to click on Global Security link under security menu.
The security configuration page opens up.
Once the security configuration page got opened click on Custom under user registries section. The custom user registry page opens.
Under general properties enter the server admin username and password you want and click on the custom properties link under Additional properties section. Click on new button in the custom properties page.
Enter groupsFile as the name and D:/IBM/security/groups.props as the value. Save the custom property value and create another custom property and enter usersFile as the name D:/IBM/security/users.props as the value. Save the values you will be returned to the custom properties page. Now the custom properties page would look like the one in the below picture.
Save the changes made and return to the security configuration page.
Now select custom user registry under active user registry and select the ‘Enable global security’ checkbox. Uncheck ‘Enforce Java 2 Security’
Save the changes. Restart your server. Once global security is enabled on the WAS server, we need to provide the admin username and password for starting and stopping the server. The command for starting the server once the security is enabled is
startServer.bat server1 -user admin -password admin
where server1 is the name of your server. If your server is integrated with an IDE like RAD, double click on the server from the server perspective and enter the username and password after selecting ’security is enabled on this server’ checkbox under security section in your server configuration window.
#####################################################################
Friday, February 19, 2010
Implementing Federated repository
Implementing Federated repository
I used information in Expand your user registry options with a federated repository in WebSphere Application Server V6.1 article for configuring federated repository
http://www.ibm.com/developerworks/websphere/techjournal/0701_ilechko/0701_ilechko.html
########################################################################
What is federated repository
Before now, the support in IBM WebSphere Application Server for environments where user information was stored in multiple independent user registries was somewhat limited. Prior to Version 6.1, the only registry options available were:
•Local operating system registry.
•A single, standalone Lightweight Directory Access Protocol (LDAP) registry.
•A single implementation of the Custom User Registry interface.
It is possible to implement a Custom User Registry that enables access to multiple other registries, but this can involve a significant development effort that ultimately would only support read-only operations.
WebSphere Application Server V6.1 provides a new option: a federated user repository. This feature makes it much simpler to use multiple repositories, since this capability is achieved through configuration -- rather than development -- with the use of the new Virtual Member Manager (VMM).
In essence, this feature provides the ability to map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is a set of independent user repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to something called a base entry within the federated repository, which is basically a starting point within the hierarchical namespace of the virtual realm.
What we are discussing here is the idea of one logical registry containing users from multiple underlying repositories. To the WebSphere Application Server runtime, there is still only one registry, and thus, all applications in the cell still share this one single registry
A federated repository enables you to use multiple repositories with WebSphere Application Server V6.1. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under single realm. All of the user repositories that are configured under the federated repository functionality are transparent to WebSphere Application Server.
Tips for multiple user repositories: The user ID and the DN for an LDAP repository must be unique in multiple user repositories that are configured under the same federated repository configuration. In addition, the federated repositories functionality in WebSphere Application Server supports the logical joining of entries across multiple user repositories when the application server searches and retrieves entries from the repositories
##################################################################################
I used information in Expand your user registry options with a federated repository in WebSphere Application Server V6.1 article for configuring federated repository
http://www.ibm.com/developerworks/websphere/techjournal/0701_ilechko/0701_ilechko.html
########################################################################
What is federated repository
Before now, the support in IBM WebSphere Application Server for environments where user information was stored in multiple independent user registries was somewhat limited. Prior to Version 6.1, the only registry options available were:
•Local operating system registry.
•A single, standalone Lightweight Directory Access Protocol (LDAP) registry.
•A single implementation of the Custom User Registry interface.
It is possible to implement a Custom User Registry that enables access to multiple other registries, but this can involve a significant development effort that ultimately would only support read-only operations.
WebSphere Application Server V6.1 provides a new option: a federated user repository. This feature makes it much simpler to use multiple repositories, since this capability is achieved through configuration -- rather than development -- with the use of the new Virtual Member Manager (VMM).
In essence, this feature provides the ability to map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is a set of independent user repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to something called a base entry within the federated repository, which is basically a starting point within the hierarchical namespace of the virtual realm.
What we are discussing here is the idea of one logical registry containing users from multiple underlying repositories. To the WebSphere Application Server runtime, there is still only one registry, and thus, all applications in the cell still share this one single registry
A federated repository enables you to use multiple repositories with WebSphere Application Server V6.1. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under single realm. All of the user repositories that are configured under the federated repository functionality are transparent to WebSphere Application Server.
Tips for multiple user repositories: The user ID and the DN for an LDAP repository must be unique in multiple user repositories that are configured under the same federated repository configuration. In addition, the federated repositories functionality in WebSphere Application Server supports the logical joining of entries across multiple user repositories when the application server searches and retrieves entries from the repositories
##################################################################################
Main components of WebSphere security
Main components of WebSphere security
WAS 6.1 Security has three main components
•Authentication protocol: The authentication protocol is used for Remote Method Invocation (RMI) over the Internet InterORB Protocol (IIOP) requests when security is enabled. WebSphere Application Server is configured to use Common Secure Interoperability Version 2 (CSIV2) by default. Secure Authentication Service has been deprecated and will be removed from future WebSphere releases. The CSIV2 is defined by the Object Management Group (OMG) as a standard authentication protocol for vendors to interoperate securely.
•Authentication mechanism: The WebSphere Application Server uses Lightweight Third Party Authentication (LTPA) as the default authentication mechanism.LTPA supports forwardable credentials and, for security reasons, a configurable expiration time is set on the credentials. The use of LTPA allows you to enable single sign-on (SSO) for your security domain
•User account repository: The WAS 6.1 server supports 4 different types of user repository
#################################################################################
WAS 6.1 Security has three main components
•Authentication protocol: The authentication protocol is used for Remote Method Invocation (RMI) over the Internet InterORB Protocol (IIOP) requests when security is enabled. WebSphere Application Server is configured to use Common Secure Interoperability Version 2 (CSIV2) by default. Secure Authentication Service has been deprecated and will be removed from future WebSphere releases. The CSIV2 is defined by the Object Management Group (OMG) as a standard authentication protocol for vendors to interoperate securely.
•Authentication mechanism: The WebSphere Application Server uses Lightweight Third Party Authentication (LTPA) as the default authentication mechanism.LTPA supports forwardable credentials and, for security reasons, a configurable expiration time is set on the credentials. The use of LTPA allows you to enable single sign-on (SSO) for your security domain
•User account repository: The WAS 6.1 server supports 4 different types of user repository
#################################################################################
Role Mapping in installed application
Role Mapping in installed application
If you did not map application roles to users during installation you can map security roles to users and groups in installed application by following these rules
•Go the WAS Admin COnsole, select the enterprise application in which you want to map roles, If your application defines roles, then you will see "Security role to user/group mapping" link in the Detail properties section, click on that link
•When you click on that link you will get a "Security role to user/group mapping" page like this, which will list out all the roles in your application and let you map those roles
##############################################################################
If you did not map application roles to users during installation you can map security roles to users and groups in installed application by following these rules
•Go the WAS Admin COnsole, select the enterprise application in which you want to map roles, If your application defines roles, then you will see "Security role to user/group mapping" link in the Detail properties section, click on that link
•When you click on that link you will get a "Security role to user/group mapping" page like this, which will list out all the roles in your application and let you map those roles
##############################################################################
Thursday, February 18, 2010
Introduction to LDAP: Part 2: LDAP and WebSphere
http://www.ibm.com/developerworks/tivoli/library/t-ldap02/#N10277
What is LDAP?
LDAP stands for Lightweight Directory Access Protocol. This is a protocol for querying and modifying directory services over TCP/IP. LDAP is an application protocol . LDAP is used for accessing and updating information in a directory. These operations include establishing sessions and disconnecting sessions. LDAP has hierarchical data format. This hierarchy usually has domain names.
Subscribe to:
Posts (Atom)







