As a general rule, two things happen when you increase security: the cost per transaction increases and throughput decreases.
By default, WebSphere for z/OS runs with security off. With security turned off there is virtually no overhead. However, we recommend that you run with security enabled, even though the runtime will always incur a small price to collect and carry the security credential information for users and the server. Compared to no security, global security for a sample application took about 13%. Compared to no security, java2 security took about 18%. Enabling a single role on every method in a sample application with global and java2 security costs about 38%.
Placing these profiles in a (RACLISTed) memory table will improve the performance of the access checks. Audit controls on access checks also affect performance. Usually, you audit failures and not successes. Audit events are logged to DASD and will increase the overhead of the access check. Since all the security authorization checks are done with SAF (RACF or equivalent), you can choose to enable and disable SAF classes to control security. A disabled class will cost a negligible amount of overhead.
If you are using EJBROLEs, specifying more roles on a method will lead to more access checks that need to be executed and a slower overall method dispatch. If you are not using EJBROLEs, do not activate the class.
For instructions on how to disable Java 2 security, refer to Configuring Java 2 security
You have several options when dealing with authentication:
WebSphere allows you to select which cipher suites you use. The cipher suites dictate the encryption strength of the connection. The higher the encryption strength, the greater the impact on performance. For more information on SSL, refer to Secure Sockets Layer.