Performance tuning is not easy and there aren’t any silver bullets, but you can go a surprisingly long way with a few basic guidelines.
In theory, performance tuning is done by a DBA. But in practice, the DBA is not going to have time to scrutinize every change made to a stored procedure. Learning to do basic tuning might save you from reworking code late in the game.
Below is my list of the top 15 things I believe developers should do as a matter of course to tune performance when coding. These are the low hanging fruit of SQL Server performance – they are easy to do and often have a substantial impact. Doing these won’t guarantee lightening fast performance, but it won’t be slow either.
1.Create a primary key on each table you create and unless you are really knowledgeable enough to figure out a better plan, make it the clustered index (note that if you set the primary key in Enterprise Manager it will cluster it by default).
2.Create an index on any column that is a foreign key. If you know it will be unique, set the flag to force the index to be unique.
3.Don’t index anything else (yet).
4.Unless you need a different behaviour, always owner qualify your objects when you reference them in TSQL. Use dbo.sysdatabases instead of just sysdatabases.
5.Use set nocount on at the top of each stored procedure (and set nocount off) at the bottom.
6.Think hard about locking. If you’re not writing banking software, would it matter that you take a chance on a dirty read? You can use the NOLOCK hint, but it’s often easier to use SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED at the top of the procedure, then reset to READ COMMITTED at the bottom.
7.I know you’ve heard it a million times, but only return the columns and the rows you need.
8.Use transactions when appropriate, but allow zero user interaction while the transaction is in progress. I try to do all my transactions inside a stored procedure.
9.Avoid temp tables as much as you can, but if you need a temp table, create it explicitly using Create Table #temp.
10.Avoid NOT IN, instead use a left outer join - even though it’s often easier to visualize the NOT IN.
11.If you insist on using dynamic sql (executing a concatenated string), use named parameters and sp_executesql (rather than EXEC) so you have a chance of reusing the query plan. While it’s simplistic to say that stored procedures are always the right answer, it’s also close enough that you won’t go wrong using them.
12.Get in the habit of profiling your code before and after each change. While you should keep in mind the depth of the change, if you see more than a 10-15% increase in CPU, Reads, or Writes it probably needs to be reviewed.
13.Look for every possible way to reduce the number of round trips to the server. Returning multiple resultsets is one way to do this.
14.Avoid index and join hints.
15.When you’re done coding, set Profiler to monitor statements from your machine only, then run through the application from start to finish once. Take a look at the number of reads and writes, and the number of calls to the server. See anything that looks unusual? It’s not uncommon to see calls to procedures that are no longer used, or to see duplicate calls. Impress your DBA by asking him to review those results with you.
If you take these 15 steps, you’ve made a really good first pass.
There’s more to learn next time as we build a model of how your application, the network, and SQL Server all offer the potential for bottlenecks. We will also look at the potential for improving performance and some more steps that you can take without stepping too far into the land of the DBA.
Friday 25 October 2013
Friday 26 July 2013
26-July-2013
http://www.studytonight.com/java/multithreading-in-java.php
1. What is major constrant need to set then any GUI will be filt in all browser ?
2. How to restrict throw AJAX a valid URL and in-valid URL ?
3. Inheritance in Spring ?
4. Detached Object in Hibernate ?
5. How I can call a simple SQL query via Hibernate ?
1. Suppose a parent class method throw some exception then it will work ?
2. What is List and Map?
3. What is the difference between String str="abc" and String str1=new String("GoodMorningIndia");
4. What is difference between Observale and Observer ?
5. What is difference between ArrayList and LinkedList ?
6. What is the difference between HashMap and HashTable.
1. What is major constrant need to set then any GUI will be filt in all browser ?
2. How to restrict throw AJAX a valid URL and in-valid URL ?
3. Inheritance in Spring ?
4. Detached Object in Hibernate ?
5. How I can call a simple SQL query via Hibernate ?
1. Suppose a parent class method throw some exception then it will work ?
2. What is List and Map?
3. What is the difference between String str="abc" and String str1=new String("GoodMorningIndia");
4. What is difference between Observale and Observer ?
5. What is difference between ArrayList and LinkedList ?
6. What is the difference between HashMap and HashTable.
Saturday 13 July 2013
Tivoi Access Manager Development ToolKit Work .
1. Administration Java classes are packaged in the PD.jar file that is installed as part of the Tivoli Access Manager Java runtime environment component.
2. Applications using the Java runtime environment provided with Tivoli Access Manager automatically have access to these classes and methods.
3. The administration API Java classes communicate directly with the Tivoli Access Manager policy server component. The API establishes an authenticated, Secure Sockets Layer (SSL) session with the Tivoli Access Manager policy server process.
4. After the SSL session is established, the classes can send administration requests to the policy server.
5.Use the SvrSslCfg Java class to provide this functionality.
Other ways to manipulate administration objects
1. pdadmin command line interface (CLI)
2. Administration C API
Administration API application development kit files
AM_BASE/nls/javadocs /pdjrte/index.html
index.html
(and
many others)
Javadoc HTML documentation for the Java classes and methods provided with the Tivoli Access Manager Java runtime component.
AM_BASE/example/ pdadminapi_demo/java
README.PDAdminDemo PDAdminDemo.java PDAdminDemo.class PDAdminDemo$ConsoleEraser.class
A demonstration program is provided which illustrates the use of the administration Java APIs. You can copy the demonstration program to any directory. The readme file explains how to run and recompile the demonstration program.
JAVA_HOME/lib/ext
PD.jar
The Java Archive (JAR) file containing the classes and methods associated with the administration APIs. Note: When you use the pdjrtecfg command line interface to configure the Tivoli Access Manager Java runtime component to a particular JRE, this archive file is copied to JAVA_HOME/lib/ext. Therefore, there is no need to modify the CLASSPATH in your environment to access the classes and methods defined in this archive file.
Notes: 1.
The Tivoli Access Manager runtime environment component is not needed for developing or deploying an Tivoli Access Manager Java application. The prerequisite checking for the Tivoli Access Manager ADK component is in error and erroneously requires that the Tivoli Access Manager runtime component be installed, even if you are developing only Java applications and simply need the Javadoc information and the example files from the ADK component. To save disk space, you can copy the Javadoc HTML information, consisting of the entire AM_BASE/nls/javadocs directory tree, along with the sample Java program, in the AM_BASE/example directory tree, to another location on your development system and then uninstall the Tivoli Access Manager ADK and runtime components. 2. If you intend to use the Tivoli Access Manager runtime environment for an administration C API application, you also must install the IBM® Directory client if an LDAP or Lotus Domino server is being used as the user registry in the secure domain.
Configuring the Java runtime component to a particular Java runtime environment Configure the Tivoli Access Manager Java runtime component to use the proper JRE on the system by using the pdjrtecfg command.
The com.tivoli.pd.jcfg.SvrSslCfg Java class must be used to configure the administration Java APIs.
Security requirements When running a Java application in the context of a Java security manager,
the application must have the proper Java permissions to use the administration Java APIs. If the application is not installed as a Java extension in the JAVA_HOME/lib/ext directory, an entry must be added to the JAVA_HOME/lib/security/java.policy file.
For example, to grant Java applications located in the /sb/pdsb/export/classes directory, and all its subdirectories, the necessary Java permissions to use authorization Java classes and methods, add a statement similar to the following to the java.policy file:
4 IBM Tivoli Access Manager for e-business:Administration
Java Classes Developer Reference Invoke administration Java classes and methods from a privileged block, doPrivileged(), to alleviate the need for the application’s callers to have this Java permission as well. The PD.jar file is signed, but verification of the signing of JAR files is not supported in this version of Tivoli Access Manager.
Enabling tracing on the policy server
To enable tracing on the policy server, edit the /etc/pdmgrd_routing file, located in the installation directory for the Tivoli Access Manager policy server, and uncomment the last line.
Shut down and restart the policy server daemon, pdmgrd.
Enabling tracing on the authorization server :
To enable tracing on the authorization server, edit the /etc/pdacld_routing file, located in the installation directory for the Tivoli Access Manager authorization server, and uncomment the last line.
Shut down and restart the authorization server daemon, pdacld.
Enabling tracing in the Java runtime component
Tracing for the Tivoli Access Manager Java runtime component is controlled by settings in the properties file created by the com.tivoli.pd.jcfg.SvrSslCfg command. To enable tracing, edit the properties file created and update the line associated with the desired application-server-name to set isLogging to true: baseGroup.PDJ<application-server-name>TraceLogger.isLogging=true Each Java application can be configured to use a different properties file, and the properties file can have any name and be located in any directory. The PDJLog.properties file, located in the PolicyDirector subdirectory of the associated JRE, is installed by the Tivoli Access Manager Java runtime environment component. This properties file is associated with, and can be used to enable tracing in, the pdjrtecfg command as well as the com.tivoli.pd.jcfg.SvrSslCfg command.
Administration objects
PDAdmin
This class is used to initialize and shut down the operations associated with using the Tivoli Access Manager administration classes and methods. The methods in this class are applicable to all administration objects.
PDContext
This class encapsulates the information needed to establish a communication session between the Java application and the Tivoli Access Manager policy server. Both user ID and password-based and certificate-based authentication are supported by this class. Multiple PDContext objects can be created and used within the same Java virtual machine (JVM).
PDPolicy
This class represents the policy information that is associated with a
particular Tivoli Access Manager user or, in the case of the global policy, that is associated with all users. The PDPolicy class is used to set and retrieve account policy information from the user registry on a global or per-user basis.
PDRgyGroupName
This class represents the name of an Tivoli Access Manager group in the underlying user registry.
PDRgyName
This class represents the name of an Tivoli Access Manager object in the underlying user registry. This object is either an Tivoli Access Manager user name or group name.
Common classes The following classes are used for both administration and authorization methods.
PDAttrs This class represents a list of Tivoli Access Manager attributes.
PDAttrValue This class represents the value of a Tivoli Access Manager attribute.
PDAttrValues This class represents a collection of values for a particular attribute that is unordered and that does not allow duplicates.
PDAttrValueList This class represents a collection of values for a particular attribute that is ordered and allows duplicates.
Initializing the administration API
PDMessages messages = new PDMessages(); PDAdmin.initialize("myApplicationName", messages);
Establishing a security context
The security context provides for the secure transfer of administrative requests and data between the Java application and the policy server.
configuration file URL The uniform resource locator (URL) to the configuration file created by the Java SvrSslCfg class.
The URL must use the file:/// format.Note:
Do not use the svrsslcfg command line interface to create a configuration file that is to be used by a Java application.
To create the security context, create a PDContext object as shown in Figure 3.
The contents of the configuration file created by the Java SvrSslCfg class is not externalized and is subject to change without notice in future releases of Tivoli Access Manager.
Users should not use the information in the configuration file directly.
Certificate-based authentication To establish a security context using certificate-based authentication, you need the following information:
locale The locale that is to be used for returning message data to the application.
configuration file URL The URL to the configuration file created by the Java SvrSslCfg class.
The URL must use the file:/// format.Note: Do not use the svrsslcfg command line interface to create a configuration file that is to be used by a Java application.
To create the security context, create a PDContext object as shown in Figure 4 on page 14. // Create locale for US English
Locale myLocale = new Locale("ENGLISH", "US");
/* Create a security context using our locale.
Need to supply a user ID with administrative privileges in Access Manager (like sec_master) along with its password and a URL of the form file:/// to the configuration file created by the SvrSslCfg class. */
PDContext myContext = new PDContext(myLocale, adminName, adminPassword, domain, configFileURL);
2. Applications using the Java runtime environment provided with Tivoli Access Manager automatically have access to these classes and methods.
3. The administration API Java classes communicate directly with the Tivoli Access Manager policy server component. The API establishes an authenticated, Secure Sockets Layer (SSL) session with the Tivoli Access Manager policy server process.
4. After the SSL session is established, the classes can send administration requests to the policy server.
5.Use the SvrSslCfg Java class to provide this functionality.
Other ways to manipulate administration objects
1. pdadmin command line interface (CLI)
2. Administration C API
Administration API application development kit files
AM_BASE/nls/javadocs /pdjrte/index.html
index.html
(and
many others)
Javadoc HTML documentation for the Java classes and methods provided with the Tivoli Access Manager Java runtime component.
AM_BASE/example/ pdadminapi_demo/java
README.PDAdminDemo PDAdminDemo.java PDAdminDemo.class PDAdminDemo$ConsoleEraser.class
A demonstration program is provided which illustrates the use of the administration Java APIs. You can copy the demonstration program to any directory. The readme file explains how to run and recompile the demonstration program.
JAVA_HOME/lib/ext
PD.jar
The Java Archive (JAR) file containing the classes and methods associated with the administration APIs. Note: When you use the pdjrtecfg command line interface to configure the Tivoli Access Manager Java runtime component to a particular JRE, this archive file is copied to JAVA_HOME/lib/ext. Therefore, there is no need to modify the CLASSPATH in your environment to access the classes and methods defined in this archive file.
Notes: 1.
The Tivoli Access Manager runtime environment component is not needed for developing or deploying an Tivoli Access Manager Java application. The prerequisite checking for the Tivoli Access Manager ADK component is in error and erroneously requires that the Tivoli Access Manager runtime component be installed, even if you are developing only Java applications and simply need the Javadoc information and the example files from the ADK component. To save disk space, you can copy the Javadoc HTML information, consisting of the entire AM_BASE/nls/javadocs directory tree, along with the sample Java program, in the AM_BASE/example directory tree, to another location on your development system and then uninstall the Tivoli Access Manager ADK and runtime components. 2. If you intend to use the Tivoli Access Manager runtime environment for an administration C API application, you also must install the IBM® Directory client if an LDAP or Lotus Domino server is being used as the user registry in the secure domain.
Configuring the Java runtime component to a particular Java runtime environment Configure the Tivoli Access Manager Java runtime component to use the proper JRE on the system by using the pdjrtecfg command.
The com.tivoli.pd.jcfg.SvrSslCfg Java class must be used to configure the administration Java APIs.
Security requirements When running a Java application in the context of a Java security manager,
the application must have the proper Java permissions to use the administration Java APIs. If the application is not installed as a Java extension in the JAVA_HOME/lib/ext directory, an entry must be added to the JAVA_HOME/lib/security/java.policy file.
For example, to grant Java applications located in the /sb/pdsb/export/classes directory, and all its subdirectories, the necessary Java permissions to use authorization Java classes and methods, add a statement similar to the following to the java.policy file:
4 IBM Tivoli Access Manager for e-business:Administration
Java Classes Developer Reference Invoke administration Java classes and methods from a privileged block, doPrivileged(), to alleviate the need for the application’s callers to have this Java permission as well. The PD.jar file is signed, but verification of the signing of JAR files is not supported in this version of Tivoli Access Manager.
Enabling tracing on the policy server
To enable tracing on the policy server, edit the /etc/pdmgrd_routing file, located in the installation directory for the Tivoli Access Manager policy server, and uncomment the last line.
Shut down and restart the policy server daemon, pdmgrd.
Enabling tracing on the authorization server :
To enable tracing on the authorization server, edit the /etc/pdacld_routing file, located in the installation directory for the Tivoli Access Manager authorization server, and uncomment the last line.
Shut down and restart the authorization server daemon, pdacld.
Enabling tracing in the Java runtime component
Tracing for the Tivoli Access Manager Java runtime component is controlled by settings in the properties file created by the com.tivoli.pd.jcfg.SvrSslCfg command. To enable tracing, edit the properties file created and update the line associated with the desired application-server-name to set isLogging to true: baseGroup.PDJ<application-server-name>TraceLogger.isLogging=true Each Java application can be configured to use a different properties file, and the properties file can have any name and be located in any directory. The PDJLog.properties file, located in the PolicyDirector subdirectory of the associated JRE, is installed by the Tivoli Access Manager Java runtime environment component. This properties file is associated with, and can be used to enable tracing in, the pdjrtecfg command as well as the com.tivoli.pd.jcfg.SvrSslCfg command.
Administration objects
PDAdmin
This class is used to initialize and shut down the operations associated with using the Tivoli Access Manager administration classes and methods. The methods in this class are applicable to all administration objects.
PDContext
This class encapsulates the information needed to establish a communication session between the Java application and the Tivoli Access Manager policy server. Both user ID and password-based and certificate-based authentication are supported by this class. Multiple PDContext objects can be created and used within the same Java virtual machine (JVM).
PDPolicy
This class represents the policy information that is associated with a
particular Tivoli Access Manager user or, in the case of the global policy, that is associated with all users. The PDPolicy class is used to set and retrieve account policy information from the user registry on a global or per-user basis.
PDRgyGroupName
This class represents the name of an Tivoli Access Manager group in the underlying user registry.
PDRgyName
This class represents the name of an Tivoli Access Manager object in the underlying user registry. This object is either an Tivoli Access Manager user name or group name.
Common classes The following classes are used for both administration and authorization methods.
PDAttrs This class represents a list of Tivoli Access Manager attributes.
PDAttrValue This class represents the value of a Tivoli Access Manager attribute.
PDAttrValues This class represents a collection of values for a particular attribute that is unordered and that does not allow duplicates.
PDAttrValueList This class represents a collection of values for a particular attribute that is ordered and allows duplicates.
Initializing the administration API
PDMessages messages = new PDMessages(); PDAdmin.initialize("myApplicationName", messages);
Establishing a security context
The security context provides for the secure transfer of administrative requests and data between the Java application and the policy server.
configuration file URL The uniform resource locator (URL) to the configuration file created by the Java SvrSslCfg class.
The URL must use the file:/// format.Note:
Do not use the svrsslcfg command line interface to create a configuration file that is to be used by a Java application.
To create the security context, create a PDContext object as shown in Figure 3.
The contents of the configuration file created by the Java SvrSslCfg class is not externalized and is subject to change without notice in future releases of Tivoli Access Manager.
Users should not use the information in the configuration file directly.
Certificate-based authentication To establish a security context using certificate-based authentication, you need the following information:
locale The locale that is to be used for returning message data to the application.
configuration file URL The URL to the configuration file created by the Java SvrSslCfg class.
The URL must use the file:/// format.Note: Do not use the svrsslcfg command line interface to create a configuration file that is to be used by a Java application.
To create the security context, create a PDContext object as shown in Figure 4 on page 14. // Create locale for US English
Locale myLocale = new Locale("ENGLISH", "US");
/* Create a security context using our locale.
Need to supply a user ID with administrative privileges in Access Manager (like sec_master) along with its password and a URL of the form file:/// to the configuration file created by the SvrSslCfg class. */
PDContext myContext = new PDContext(myLocale, adminName, adminPassword, domain, configFileURL);
Manipulating
administration objects
Each Java class
representing an administration object provides static methods to create, list,
modify, and delete objects stored on the Tivoli Access Manager policy server.
String name =
"Stephanie Luser";
String firstName =
"Stephanie";
String lastName =
"Luser";
String password =
"herpassword";
String description =
"Descriptive text for Stephanie Luser";
String rgyName =
"cn=" + name + "," + rgySuffix;
PDRgyUserName
pdRgyUserName = new PDRgyUserName(rgyName, firstName, lastName);
boolean ssoUser = false;
boolean pwdPolicy = true;
ArrayList groupList = new
ArrayList();
groupList.add(groupAdministrativeAssistants);
messages.clear();
PDUser.createUser(mySecurityContext,
name, pdRgyUserName, description, password.toCharArray(), groupList, ssoUser,
pwdPolicy, messages);
Obtaining a local copy
of an object To obtain a local copy of an administration object, use
the constructor for the Java class representing the administration object. For
example, to get a copy of the PDUser object
representing a particular Tivoli Access Manager user, you would use the PDUser constructor.
This is shown in Figure 6.
/*------------------------------------------------------------------
* Create a user, using the PDUser.createUser() static method, and * assign the
user to a specific group. This method sends a * request to the policy server to
create the user.
*------------------------------------------------------------------ */ //
Set up all of the user’s attributes
String
name = "Stephanie Luser";
String
firstName = "Stephanie";
String
lastName = "Luser";
String
password = "herpassword";
String
description = "Descriptive text for Stephanie Luser";
String
rgyName = "cn=" + name + "," + rgySuffix;
PDRgyUserName
pdRgyUserName = new PDRgyUserName(rgyName, firstName, lastName);
boolean
ssoUser = false;
boolean
pwdPolicy = true;
ArrayList
groupList = new ArrayList();
groupList.add(groupAdministrativeAssistants);
messages.clear();
PDUser.createUser(mySecurityContext,
name, pdRgyUserName, description, password.toCharArray(), groupList, ssoUser,
pwdPolicy, messages);
Figure 5.
Creating a user /*------------------------------------------------------------------
* Obtain a user using the PDUser constructor. *------------------------------------------------------------------
*/ // Set up all of the user’s attributes String name = "Zachary
Wommbat"; String firstName = "Zachary"; String lastName =
"Wommbat"; String rgyName = "cn=" + name + "," +
rgySuffix; PDRgyUserName pdRgyUserName = new PDRgyUserName(rgyName, firstName,
lastName); messages.clear() PDUser user = new PDUser(mySecurityContext,
pdRgyUserName, messages);
Note:
After
a local copy of an administration object is obtained, the object could be changed on the policy server
by other users using the command line interface, the administration C
API, or the Java classes and methods.
The instance method changes both the local copy of the
administration object as well as the object stored on the policy server.
user.setAccountValid(mySecurityContext,
false, // Disable the account messages);
The
instance method changes both the local copy of the administration object as well
as the object stored on the policy server.
To
update the PDUser object on the policy server, use the
static method:
PDUser.setAccountValid(mySecurityContext,
name, false, // Disable the account messages);
This chapter contains the following topics:
1. Administering users” v “
2. Administering user information”
3. Administering user account policies”
4. Administering user password policies”
5. Administering groups”
6. Administering group information”
1. Administering users” v “
2. Administering user information”
3. Administering user account policies”
4. Administering user password policies”
5. Administering groups”
6. Administering group information”
Administering users
PDUser.createUser
PDUser.importUser
PDUser.deleteUser
PDUser.listUsers :Lists Tivoli Access Manager users.
The PDUser.importUser method imports an existing user definition from the user registry into Tivoli Access Manager and allows the user definition to be managed by Tivoli Access Manager.
Administering user information
When a user account has been created in the user registry, you can set and get different pieces of information about the user. You must create a security context between the calling application and the Tivoli Access Manager policy server before you can access the user registry. You can obtain the user registry information for a user object by specifying either the Tivoli Access Manager user name or the user registry name.
Below are the method through we can Administrate the Used
PDUser.createUser
PDUser.importUser - Use when user is altready there
PDUser.deleteUser
PDUser.listUser
Administereting User Information :
Below are the method through we can Administrate the Used
PDUser.createUser
PDUser.importUser - Use when user is altready there
PDUser.deleteUser
PDUser.listUser
Administereting User Information :
PDUser constructor
PDUser object.getDescription = Returns the user description.
PDUser object.getRgyName = Returns the user registry name for the user.
PDUser object.getId = Returns the name of the object.
PDUser object.getFirstName = Returns the first-name attribute for the user.
PDUser object.getLastName = Returns the last-name attribute for the user.
PDUser object.getPolicy = Returns the password and account policy settings associated with the user.
PDUser object.getGroups = Lists the groups in which the user is a member.
PDUser object.isAccountValid = Returns the account-valid indicator for the user.
PDUser object.isPDUser = Returns a setting that indicates if this is an Tivoli Access Manager user.
PDUser object.isSSOUser = Returns a setting that indicates if the user has single signon capabilities.
PDUser.setDescription PDUser object.setDescription = Sets a user description.
PDUser.setAccountValid PDUser object.setAccountValid = Enables or disables a user account.
PDUser.setSSOUser PDUser object.setSSOUser= Enables or disables the single signon capabilities of a user.
PDUser object.isPasswordValid = Returns the enabled indicator for the user’s password.
PDUser.setPassword PDUser object.setPassword = Sets a user’s password.
PDUser.setPasswordValid PDUser object.setPasswordValid
PDUser object.getDescription = Returns the user description.
PDUser object.getRgyName = Returns the user registry name for the user.
PDUser object.getId = Returns the name of the object.
PDUser object.getFirstName = Returns the first-name attribute for the user.
PDUser object.getLastName = Returns the last-name attribute for the user.
PDUser object.getPolicy = Returns the password and account policy settings associated with the user.
PDUser object.getGroups = Lists the groups in which the user is a member.
PDUser object.isAccountValid = Returns the account-valid indicator for the user.
PDUser object.isPDUser = Returns a setting that indicates if this is an Tivoli Access Manager user.
PDUser object.isSSOUser = Returns a setting that indicates if the user has single signon capabilities.
PDUser.setDescription PDUser object.setDescription = Sets a user description.
PDUser.setAccountValid PDUser object.setAccountValid = Enables or disables a user account.
PDUser.setSSOUser PDUser object.setSSOUser= Enables or disables the single signon capabilities of a user.
PDUser object.isPasswordValid = Returns the enabled indicator for the user’s password.
PDUser.setPassword PDUser object.setPassword = Sets a user’s password.
PDUser.setPasswordValid PDUser object.setPasswordValid
Administering user account policies
PDUser.getUserRgy = Return the registory Name of the user in which Tivoli Access Manager Registry is used by PDUser
PDPolicy obj.accDisableEnforcedTime
PDPolicy obj.accDisableEnforcedUnlimite
PDPolicy obj.accExpDateEnforced
PDPolicy obj.accExpDateUnlimited
PDPolicy obj.accAccExpDate
PDPolicy obj.accAccDisableTimeInterval
PDPolicy obj.getMaxFailed
PDPolicy obj.setMaxFailed
PDPolicy obj.getAccessibleDay
PDPolicy obj.getAccessibleStartTime
PDPolicy obj.getAccessibleEndTime
PDPolicy obj.maxFailedloginEnforced
PDPolicy obj.setAccExpDate
PDPolicy obj.setActDisableTime
PDPolicy obj.MaxFailedLogin
PDPolicy obj.setTodAccess
PDPolicy obj.setTodAccessEnforced
I have workd on Administration of the
1. Administaton of User
PDUser.createUser();
PDUser.importUser();
PDUser.deleteUser();
PDUser.listUser();
2. Administartion of User Inforamtion
PDUser.getDiscription();
PDUser.getRgyName();
PDUser.getID();
PDUser.getFirstName();
PDUser.getLastName();
PDUser.isAccValid();
3. Administration of User Account Policy
PDUSer.getDescription();
PDPolicy obj.getMaxLenght();
PDPolicy obj.getMaxAplhaEnforced();
PDPolicy obj.getMax
4. Administartion of User Password Policy
PDPolicy obj.setMaxPwdLength();
PDPolicy obj.setMaxAlphaChar();
PDPolicy obj.setMaxExpiryDate();
5. Administartion of Group Policy
PDGroup.createGroup();
PDGroup.importGroup();
PDGroup.deleteGroup();
PDGroup.listGroup();
6. Administartion of Group Information
PDGroup obj.getDescription();
PDGroup obj.getRgyName();
PDGroup obj.getID();
PDGroup obj.isPDGroup();
PDGroup obj.addMember();
PDGroup obj.getMember();
PDGroup obj.removeMember();
PDUser.getUserRgy = Return the registory Name of the user in which Tivoli Access Manager Registry is used by PDUser
PDPolicy obj.accDisableEnforcedTime
PDPolicy obj.accDisableEnforcedUnlimite
PDPolicy obj.accExpDateEnforced
PDPolicy obj.accExpDateUnlimited
PDPolicy obj.accAccExpDate
PDPolicy obj.accAccDisableTimeInterval
PDPolicy obj.getMaxFailed
PDPolicy obj.setMaxFailed
PDPolicy obj.getAccessibleDay
PDPolicy obj.getAccessibleStartTime
PDPolicy obj.getAccessibleEndTime
PDPolicy obj.maxFailedloginEnforced
PDPolicy obj.setAccExpDate
PDPolicy obj.setActDisableTime
PDPolicy obj.MaxFailedLogin
PDPolicy obj.setTodAccess
PDPolicy obj.setTodAccessEnforced
I have workd on Administration of the
1. Administaton of User
PDUser.createUser();
PDUser.importUser();
PDUser.deleteUser();
PDUser.listUser();
2. Administartion of User Inforamtion
PDUser.getDiscription();
PDUser.getRgyName();
PDUser.getID();
PDUser.getFirstName();
PDUser.getLastName();
PDUser.isAccValid();
3. Administration of User Account Policy
PDUSer.getDescription();
PDPolicy obj.getMaxLenght();
PDPolicy obj.getMaxAplhaEnforced();
PDPolicy obj.getMax
4. Administartion of User Password Policy
PDPolicy obj.setMaxPwdLength();
PDPolicy obj.setMaxAlphaChar();
PDPolicy obj.setMaxExpiryDate();
5. Administartion of Group Policy
PDGroup.createGroup();
PDGroup.importGroup();
PDGroup.deleteGroup();
PDGroup.listGroup();
6. Administartion of Group Information
PDGroup obj.getDescription();
PDGroup obj.getRgyName();
PDGroup obj.getID();
PDGroup obj.isPDGroup();
PDGroup obj.addMember();
PDGroup obj.getMember();
PDGroup obj.removeMember();
Friday 12 July 2013
Tivoli Access Manager Prerequisite products
Prerequisite products
Tivoli Access Manager includes the following prerequisite products. These products are shipped with Tivoli Access Manager and are required when setting up specific Tivoli Access Manager systems. For a list of required installation components necessary to set up a Tivoli Access Manager system, see Table 1.
IBM Global Security Kit
IBM Global Security Kit (GSKit) provides Secure Sockets Layer (SSL) data encryption between Tivoli Access Manager systems and supported registry servers. The GSKit package also installs the iKeyman key management utility (gsk7ikm), which enables you to create key databases, public-private key pairs, and certificate requests.
You must install GSKit before installing most other Tivoli Access Manager components. GSKit is a prerequisite to the Access Manager Runtime component, which is required on all Tivoli Access Manager systems with the exception of Java runtime environment, Web Portal Manager, and Attribute Retrieval Service systems. For information about using this utility to enable SSL with a supported registry server, seeEnabling Secure Sockets Layer or refer to the IBM Global Security Kit Secure Sockets Layer and iKeyman User's Guide.
Note:
OpenSSL is included in GSKit and may be used for cryptographic operations (as per the OpenSSL license agreement).
IBM Java Runtime Environment (JRE)
IBM JRE is required when installing the Access Manager Java Runtime Environment component, language support packages, or using Tivoli Access Manager installation wizards.
IBM Tivoli Directory Client
The IBM Tivoli Directory Client is shipped with IBM Tivoli Directory Server on the IBM Tivoli Access Manager Directory Server CD for supported AIX, HP-UX, Linux, Solaris, and Windows platforms.
You must install the IBM Tivoli Directory Client on each system that runs Tivoli Access Manager, with the following exceptions:
- The Tivoli Access Manager system is a supported Windows system that is joined to an Active Directory domain.
- You are setting up a Java runtime environment, Web Portal Manager, or attribute retrieval service system.
- You are using Lotus Domino as your registry server.
IBM Tivoli Directory Server
IBM Tivoli Directory Server, Version 5.2, is shipped on the IBM Tivoli Access Manager Directory Server CD for supported AIX, HP-UX, Linux, Sun Solaris Operating Environment, and Windows platforms. You can use this server as your Tivoli Access Manager registry server or use one of the registry servers listed in Supported registries. This Lightweight Directory Access Protocol (LDAP) directory runs as a stand-alone daemon. It is based on a client/server model that provides client access to an LDAP server. The IBM Tivoli Directory Server provides an easy way to maintain directory information in a central location for storage, updating, retrieval, and exchange.
IBM Tivoli Directory Server Web Administration Tool
IBM Tivoli Directory Server, Version 5.2, provides the Web Administration Tool--a separately installable GUI that runs on an application server, such as the IBM WebSphere Application Server. Use the Web Administration Tool to administer IBM Tivoli Directory servers either locally or remotely. You can install a single Web Administration console to manage multiple IBM Tivoli Directory servers, including Version 4.1, 5.1, and 5.2 servers.
The Web Administration Tool is shipped separately on the IBM Tivoli Access Manager Web Administration Interfaces CD. For system requirements, including supported browsers, see IBM Tivoli Directory Server Web Administration Tool.
IBM WebSphere Application Server
IBM WebSphere Application Server 5.0.2 is used for installation of the Web Portal Manager interface, the attribute retrieval service, and the Web Administration Tool. IBM WebSphere Application Server is shipped on the IBM Access Manager Web Administration Interfaces CD for supported platforms.
Note that IBM Tivoli Directory Server, Version 5.2, usually ships WebSphere Application Server -- Express version for use with its Web Administration Tool. In Tivoli Access Manager, Version 5.1, this simplified Web server application was replaced with IBM WebSphere Application Server, V5.0.2--the premier Java 2 Enterprise Edition (J2EE) and Web services technology-based application platform, offering one of the first production-ready application servers for the deployment of enterprise Web services solutions for dynamic e-business on demand.
Component of Tivoli Access Manager
Access Manager, Version 5.1
Tivoli Access Manager Base components
Tivoli Access Manager Base includes the following installation components. These components are shipped on the IBM Tivoli Access Manager Base CD for supported platforms with the exception of the Web Portal Manager component, which is shipped on the IBM Tivoli Access Manager Web Administration Interfaces CD. Use these installation components to set up Base systems listed in Tivoli Access Manager Base systems.
Access Manager Application Development Kit
The Access Manager Application Development Kit provides a development environment that enables you to code third-party applications to query the authorization server for authorization decisions. This kit contains support for using both C APIs and Java(TM) classes for authorization and administration functions. To run the Java program or to compile and run your own Java programs, you must install and configure a Java runtime environment system.
Access Manager Authorization Server
The Access Manager Authorization Server provides access to the authorization service for third-party applications that use the Tivoli Access Manager authorization API in remote cache mode. The authorization server also acts as a logging and auditing collection server to store records of server activity.
Access Manager Java Runtime Environment
The Access Manager Java Runtime Environment offers a reliable environment for developing and deploying Java applications in a Tivoli Access Manager secure domain. Use it to add Tivoli Access Manager authorization and security services to new or existing Java applications.
You can use the pdjrtecfg command to configure this component to use the proper JRE on your system. You can also configure this component to several different JREs on the same system, if so desired.
Note that if you plan to install the Web Portal Manager interface, this component is required. It is also required with the Access Manager Application Development Kit component if you are a developer using Tivoli Access Manager Java runtime environment classes. For more information, see the IBM Tivoli Access Manager for e-business Administration Java Classes Developer Reference and the IBM Tivoli Access Manager for e-business Authorization Java Classes Developer Reference.
Access Manager Policy Proxy Server
The Access Manager Policy Proxy Server is used to set up a proxy server, which acts as an intermediary between a less trusted network and a more trusted network. This server ensures security and provides administrative control and caching services. It is associated with or part of a gateway server that separates the enterprise network from the outside network, and a firewall server that protects the enterprise network from outside intrusion. In a Tivoli Access Manager environment, the proxy server runs on behalf of the policy server for a given number of authorization applications and administrative functions, such as pdadmin commands.
Access Manager Policy Server
The Access Manager Policy Server maintains the master authorization database for the management domain as well as the policy databases associated with other secure domains that you might decide to create. This server is key to the processing of access control, authentication, and authorization requests. It also updates authorization database replicas and maintains location information about other Tivoli Access Manager servers.
Optionally, you can configure a standby server to take over policy server functions in the event of a system failure or unplanned outage. When the policy server goes down, the standby policy server acts as the primary policy server until the primary policy server assumes its original role. In turn, the standby policy server reverts back to a standby role. At any given time, there is only one active policy server andonly one shared copy of the policy databases.
Tivoli Access Manager supports the use of one standby policy server on supported AIX platforms. In addition, deploying a standby policy server requires the installation and configuration of High Availability Cluster Multiprocessing (HACMP) software--a clustering solution designed to provide high-availability access to business-critical data and application through component redundancy and application failover.
Access Manager Runtime
The Access Manager Runtime contains runtime libraries and supporting files that applications can use to access Tivoli Access Manager servers.
You must install and configure the Access Manager Runtime component on each system that runs Tivoli Access Manager except for Web Portal Manager and Java runtime environment systems.
Access Manager Web Portal Manager
The Access Manager Web Portal Manager is a Web-based graphical user interface (GUI) used for Tivoli Access Manager administration. Similar to the pdadmin command line interface, this GUI provides management of users, groups, roles, permissions, policies, and other Tivoli Access Manager tasks. A key advantage is that you can perform these tasks remotely, without requiring any special network configuration.
The Web Portal Manager interface also includes a set of delegated management services that enables a business to delegate user administration, group and role administration, security administration, and application access provisioning to participants (sub-domains) in the business system. These sub-domains can further delegate management and administration to trusted sub-domains under their control.
This component is shipped separately on the IBM Tivoli Access Manager Web Administration Interfaces CD. Supported browsers for the Web Portal Manager interface are as follows:
- Netscape Navigator 4.7x and 7.0
- Microsoft Internet Explorer 5.5 and 6.0
Provisioning Fast Start
A Provisioning Fast Start Installer is provided on the Tivoli Access Manager Base CDs for AIX and Windows platforms. Use this installer to install a Provisioning Fast Start collection of utilities that can help you integrate Tivoli Access Manager with Tivoli Identity Manager (which is a separately orderable IBM product). The tasks supported by these utilities include:
- Creating a Tivoli Access Manager service and provisioning policy on the Tivoli Identity Manager server
- Configuring Tivoli Identity Manager for use with WebSEAL single sign-on
- Importing and synchronizing user data in Tivoli Identity Manager
- Creating a Web interface for user management with Tivoli Identity Manager
LDAP and JNDI: Together forever
Learn how LDAP and JNDI combine to form a powerful directory and Java object storage facility
- Feedback
- 13 Comments
(Note: To download this article's complete source code, see theResources section below.)
LDAP's basic structure is based on a simple information tree metaphor called a directory information tree (DIT). Each leaf in the tree is an entry; the first or top-level entry is the root entry. An entry includes a distinguished name (DN) and any number of attribute/value pairs. The DN, which is the name of an entry, must be unique. It shows the relationship between the entry and the rest of the DIT in a manner similar to the way in which a file's full path name shows its relationship with the rest of the files in a filesystem. While a path to a file reads left to right, a DN, in contrast, reads from right to left. Here is an example of an DN:
uid=styagi,ou=people,o=myserver.com
The leftmost part of the DN, called a relative distinguished name(RDN), is made up of an attribute/value pair. In the above example, this pair would be
uid=styagi. LDAP attributes often use mnemonics, some examples of which are listed in Table 1.o | Organization |
ou | Organizational unit |
cn | Common name |
sn | Surname |
givenname | First name |
uid | Userid |
dn | Distinguished name |
mail | Email address |
Information about attributes, attribute matching rules, and relationships between objectclasses are defined in the server'sschema. Any attribute can have one or more values, depending on how it is defined the schema. A user, for example, can have more than one email address. There is also a special attribute called anobjectclass that specifies the required and allowed attributes for a particular entry. Like objects in Java, objectclasses in LDAP can be extended to retain existing attributes and add new ones.
A naming service associates names with objects and finds objects based on their given names. (The RMI registry is a good example of a naming service.) Many naming services are extended with adirectory service. While a naming service allows a lookup of an object based on its name, a directory service also allows such objects to have attributes. As a result, with a directory service we can look up an object's attributes or search for objects based on their attributes.
So where does JNDI fit into this LDAP jargon? JNDI does for LDAP what JDBC does for Oracle -- it provides a standard API for interacting with naming and directory services using a service provider interface (SPI), which is analogous to an JDBC driver. LDAP is a standard way to provide access to directory information. JNDI gives Java applications and objects a powerful and transparent interface to access directory services like LDAP. Table 2 below outlines common LDAP operations and their JNDI equivalents. (For a detailed look at the JNDI specification, seeResources.)
| Operation | What it does | JNDI equivalent |
| Search | Search directory for matching directory entries | DirContext.search() |
| Compare | Compare directory entry to a set of attributes | DirContext.search() |
| Add | Add a new directory entry | DirContext.bind(),DirContext.createSubcontext() |
| Modify | Modify a particular directory entry | DirContext.modifyAttributes() |
| Delete | Delete a particular directory entry | Context.unbind(), Context.destroySubcontext() |
| Rename | Rename or modify the DN | Context.rename() |
| Bind | Start a session with an LDAP server | new InitialDirContext() |
| Unbind | End a session with an LDAP server | Context.close() |
| Abandon | Abandon an operation previously sent to the server | Context.close(), NamingEnumneration.close() |
Extended | Extended operations command | LdapContext.extendedOperation() |
Manipulate objects in the LDAP server
Let's cut to the chase and see how to manipulate objects in the LDAP server. The standard LDAP operations include:
- Connect to the server
- Bind to the server (think of this as authentication)
- Add new entries in the LDAP server
- Modify an entry
- Delete an entry
- Search the server for an entry
We'll examine each of these steps in the sections below, with examples.
Before executing the examples, you will need to install the LDAP server, the JNDI classes, and (unless you want to disable schema checking) the Java schema. You can find install information in the JNDI zip file's schema directory. Our examples use Netscape Directory Server 4.1 and JDK 2. (To install these packages, see Resources.)
Connect to the server
To connect to the server, you must obtain a reference to an object that implements the
DirContext interface. In most applications, this is done by using an InitialDirContext object that takes a Hashtable as an argument. The Hashtablecontains various entries, such as the hostname, port, and JNDI service provider classes to use:Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldap://localhost:389"); DirContext ctx = new InitialDirContext(env);
Bind to the Server
Once connected, the client may need to authenticate itself; this process is also known as binding to the server. (Be aware that the word binding can also refer to the act of adding something to the directory.)
In LDAP version 2, all clients had to authenticate while connecting, but version 3 defaults to anonymous and, if the default values are used, the connections are anonymous as well. LDAP servers maintain rights using access control lists (ACLs) that determine what particular access is available to an entry by an application. LDAP supports three different security types:
- Simple: Authenticates fast using plain text usernames and passwords.
- SSL: Authenticates with SSL encryption over the network.
- SASL: Uses MD5/Kerberos mechanisms. SASL is a simple authentication and security layer-based scheme
The client authenticates itself to the server by specifying values for different environment variables in the
Context interface, as seen below:Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldap://localhost:389"); env.put(Context.SECURITY_AUTHENTICATION,"simple"); env.put(Context.SECURITY_PRINCIPAL,"cn=Directory Manager"); // specify the username env.put(Context.SECURITY_CREDENTIALS,"password"); // specify the password DirContext ctx = new InitialDirContext(env);
Add new entries in the LDAP server: The options
The LDAP directory server can act as a repository for Java objects. JNDI provides an object-oriented view of this directory, which means that Java objects can be added to and retrieved from the directory without the client needing to manage data representation issues.
Objects can be stored in three ways:
- Store the Java objects themselves
- Store a reference to the object
- Store information as attributes
Let's take a look at each of these in more detail.
Store the Java objects themselves
If a class implements the
java.io.Serializable interface, it can be serialized and deserialized from storage media. If we need a simple name-object binding (as in the RMI registry), then theContext.bind() method can store the object. But if we need the more powerful technique of associating attributes with the stored object, we'd employ the DirConext.bind() method instead. Whichever method we use, the object's state is serialized and stored in the server:MyObject obj = new MyObject();
ctx.bind("cn=anobject", obj);
Once stored, we can retrieve the object by looking up its name in the directory:
MyObject obj = (MyObject)ctx.lookup("cn=anobject");
When an application serializes an object by writing it to an object stream, it records information that identifies the object's class in the serialized stream. However, the class's definition, which is contained in the classfile, is not itself recorded. The system that deserializes the object is responsible for determining how to locate and load the necessary class files.
Alternatively, the application can record the codebase with the serialized object in the directory, either when the binding occurs or by subsequently adding an attribute using
DirContext.modifyAttributes(). (We'll examine this second technique later in this article.) Any attribute can record the codebase as long as the application reading back the object is aware of the attribute name. As another option, we can employ the attribute "javaCodebase" specified in the LDAP schema for storing Java objects if schema checking is enabled on the server.
The above example can be modified to supply a codebase attribute containing the location of the
MyObject class definition:// Create object to be bound
MyObject obj = new MyObject();
// Perform bind and specify codebase
BasicAttribytes battr = new BasicAttributes("javaCodebase","http://myserver.com/classes")
ctx.bind("cn=anobject", obj, battr)
import java.util.Hashtable; import javax.naming.Context; import javax.naming.NamingEnumeration; import javax.naming.directory.Attribute; import javax.naming.directory.Attributes; import javax.naming.directory.DirContext; import javax.naming.directory.InitialDirContext; import javax.naming.directory.SearchControls; import javax.naming.directory.SearchResult; public class LdapSearch { public static void main(String[] args) throws Exception { Hashtable env = new Hashtable(); String sp = "com.sun.jndi.ldap.LdapCtxFactory"; env.put(Context.INITIAL_CONTEXT_FACTORY, sp); String ldapUrl = "ldap://localhost:389/dc=yourName, dc=com"; env.put(Context.PROVIDER_URL, ldapUrl); DirContext dctx = new InitialDirContext(env); String base = "ou=People"; SearchControls sc = new SearchControls(); String[] attributeFilter = { "cn", "mail" }; sc.setReturningAttributes(attributeFilter); sc.setSearchScope(SearchControls.SUBTREE_SCOPE); String filter = "(&(sn=W*)(l=Criteria*))"; NamingEnumeration results = dctx.search(base, filter, sc); while (results.hasMore()) { SearchResult sr = (SearchResult) results.next(); Attributes attrs = sr.getAttributes(); Attribute attr = attrs.get("cn"); System.out.print(attr.get() + ": "); attr = attrs.get("mail"); System.out.println(attr.get()); } dctx.close(); } }
Subscribe to:
Posts (Atom)