ibm confidential | january 2005 presentation subtitle: 20pt arial regular, teal r045 | g182 | b179...

IBM Confidential | January 2005 © 2005 IBM Corporation

Barb SmithBrian KringsScott McCreadieTherese Dalton

VE Single Signon Education

2 VE Release 2 | IBM Confidential © 2004 IBM Corporation

Agenda

Topics to be covered are: Overview of VE Single Sign-On

Install information

VE Single Sign-On configuration information

VE Single Sign-On runtime processing

Detailed VE Single Sign-On configuration information


VE SSO Project Deliverables

Integrated/consistent security throughout the VE Console

Extensible single sign-on architecture

Simplified VE Console based management interface for the single sign-on architecture

Single sign-on experience to end users of the VE Console Once end users sign on to the console, they can successfully launch

any application without being prompted again for another user ID and password for that application or system


VE R2 Security Goals

Goals Lessen the cost to manage security of VE

Exploit security customers have already configured to protect existing resources

Build infrastructure on which can be exploited by future enterprise security management function in the VE.

Non Goals Provide enterprise security management

Develop “all encompassing” VE specific security environment


Approach

Exploit existing security managers which protect access to existing resources

Single Sign-on Environment that can be used to lessen the cost of managing SSO by: Providing a centralized interface for caching userID/pwd where caching a

password is necessary

Provide an “ID Context Reference” function that can be exploited transparently for most applications if the underlying authentication interfaces are enhanced to support it


Install Information

VE Single Sign-On support is installed with the base VE support. It is always installed. You cannot select to install or uninstall this support. Refer to the Installation presentation for information on installing VE.

VE Single Sign-On support is used by the WAS based applications (VE Console, Console Bridges) to authenticate to applications they use that run outside of WAS. When the WAS applications are installed, they are automatically configured to

use the VE Single Sign-On support. Therefore, the configuration necessary to use single sign-on must be done before using these applications.


SSO Needs

Repository for storing SSO information (GCR & IMR) Associations set up between VE Console users and a user on the target

system The mapping lookup code needs to determine if a cached password is

required by the target application for the target system or if identity context references are supported instead.

The GUI needs to know all of the target systems that are participating in SSO for the VE Console.

The GUI needs to determine whether a cached password should also be established for the user on the target system.

EWLM and RDS have special needs


Basic Setup

Target systems participating in SSO need to be configured (install/configuration/GUI)

Target applications participating in SSO should be registered

Enroll VE console users to participate in SSO (GUI)

Associate target users on target systems with VE console users (GUI) Password for target user cached if target applications on the target system

do not support Identity Context References for authentication.


Configuration Players

Install

Configuration

GUI interfaces

Command interfaces


Install Processing

Common Runtime Collect GCR configuration information (requires customer input)

Collect IMR configuration information (requires customer input) IMR configuration information stored in the GCR (host, port, connect information)

Default configuration information for each SSO application stored in the GCR.

IMR Domain created for new VE installations.

IMR configured to support Policy Associations.

IMR registry representing the VE console user registry will be set up. Special handling will be performed to see if an existing registry was already created by Management Central to represent VE console users from R1.

Autonomic source information is created


Install Processing

Suite Installer Post-install java bean that can be called by target SSO applications to register

that specific instance of the application running on that host. Registers application instance information in the GCR. Target registry created in the IMR.

Current users: Management Central Bridge on behalf of the Management Central server eCare

vessoconfig command script Provides support for registering application SSO information and configuring

IMR SSO information Called by Director Bridge on behalf of the Director Server


Configuration

RDS special processing for Application Associations in the GUI GUI interface provided that is called by RDS during their configuration (RDS

Credential processing).

Registers the application instance in the GCR

Configures the target IMR registry

Target association added for the application to the target registry

Additional information of targetHost:targetAppId:targetPort added to the GCR and to the target user

eWLM special processing Special interfaces provided that are used during eWLM Domain Manager

configuration.

Registers the application instance in the GCR

Configures the target IMR registry

Default registry policy association added for the target identity to the target registry.


SSO GUI

Welcome Portlet

SSO Welcome Portlet

Configuration Portlet

Manage User Associations Create User Association Browse Systems Add System User Identity Association Properties

Manage Application Associations Application Association Properties

Authentication Failure Portlet

14

VE Security | IBM Confidential © 2005 IBM Corporation

Welcome Portlet

For single sign-on, this displays the status of the single sign-on configuration for the current (signed on) VE user. It checks to see if there are associations created for the management sources currently defined for the user.

15


SSO Welcome Portlet

16


SSO Welcome Portlet The main page for single sign-on configuration.

VE Administrators can manage everything in this portlet. VE Users cannot :► Create new user identity associations► Edit existing identity associations (other than setting the password for their own

associations)► Manage Application Associations (they will not see this link)► Edit SSO Configuration settings (they have read only access to this info)

User Identity Associations► Associations set up for VE console users.► Two kinds : Default (policy) & specific user associations

Application Associations► Associations that are 'autonomic' for VEC use only.► RDS only user of these.► These can and probably will be managed thru the RDS GUI.► No Create Application Association support (must be done via the RDS GUI)

Configuration ► Contains SSO settings like IMR connection information

17


Configuration Portlet

Contains configuration information for the IMR Use the Verify Configuration button to validate the settings and get detailed information

on connection problems to the IMR Information initially set at VE install time Only VE Administrators can modify.

18


Manage User Associations

Use this to manage associations for one or more users (change via the Change View button)

VE administrators can manage associations from this panel Can use the context menu "Set Password" option to cache/update several passwords

at once if the passwords are the same

19


Create User Association

Can add multiple associations at a time from this panel. Only one association can be created for a given "system" (to prevent ambiguous results

during mapping resolution) Note that if a password needs to be cached/specified, a subsequent update of the

association is required

20


Browse Systems

You can get here by clicking the Select button from the Create User Association panel Displays the list of systems that do not already have associations created for them. If the system you need is not in the list, use the New select action to display the Add System

panel

21


Add System

System list is primed with names of management sources that currently are not in the system list.

Type is the IMR user registry type. VE application table selection is optional and will register the application instance.

22


User Identity Association Properties

Information about the selected association. VE Administrators can modify the system user field. Indicates whether a password is needed for this association. A VE User can update

their own password.

23


Manage Application Associations

Currently only RDS supports Application Associations No Create Application Association support (done thru RDS GUI) Only VE administrators can manage application associations Can use the context menu "Set Password" option to cache/update several passwords

at once if the passwords are the same

24


Application Association Properties

Info about selected association Indicates whether a password is needed for this association.

25


Authentication Failure Portlet

Some VE functions provide the support for creating/updating SSO associations 'on the fly' when authentication failures to remote systems occur from within the VE console.

Not all VEC functions support this. Health Center and Virtualization Engine Updates (eCare) support this. Still pursuing RDS and Launch In Context.

26


vessoconfig command script Actions performed by the command:

► Set/View/Remove Default settings for an application

► Set/View/Remove specific instance settings for an application

► Configure/Remove System or Application registry for a system

► Set/View/Remove additional information to be used during a mapping lookup (stored in the GCR)

► Set/View/Remove additional information for a target user (added to the target user so that it is found during a mapping lookup)

► Set/View Identity Context and Authentication Context timeout values

The vessoconfig command script exists in the /bin directory of the VE install

27


Mapping Lookup Players

Application configured to use a Resource Adaptor (JCA), which is configured to use the SSO JAAS Mapping Module

Identity Context Reference processing

► VESSOEnablerServlet

28


JAAS Mapping Module

WAS based applications (e.g. VE Console, Bridges, etc.) that need to access a resource outside of WAS will use a JCA connector to obtain the credentials needed to connect to the other resource. The JCA connector will be configured to use the SSO JAAS Mapping Module (MM) to obtain the credentials.► Some applications will use the JCA connector to do the actual connection, but most

just use it to obtain the credentials and then use another connection method.

The SSO JAAS MM will use the SSO configuration information to obtain the necessary credentials. It is passed the following information by the using application:► Source application ID

► Target application ID

► Target host name

► Target port

► Autonomic indicator (optional, default is ‘N’)

29


JAAS Mapping Module

The JAAS MM retrieves the SSO configuration information for the target application:► First looks for instance specific information in the GCR based on the target application ID and

target host name.– If not found, looks for default information based on the target application ID.

● If not found, uses the system defaults of USER for authentication method and SYSTEM for SSO registry type.

It determines the authentication method used by the target application based on the SSO configuration information. Possible values are:► USER = authenticates using a user ID and password.

► IDENTITY_CONTEXT = authenticates using an Identity Context Reference. Allows authentication without having to cache a password. The only application that currently supports this method is IBM Director Server 5.1.

It determines the SSO registry type for the target application based on the SSO configuration information. Possible values are:► SYSTEM = credential information is for a user in the system registry. Only need the target host

name to determine the target registry.

► APPLICATION = credential information is for a user in an application registry. Need both the target host name and port to determine the target registry. The only application that currently uses application registries is EWLM.

30


JAAS Mapping Module

Performs a mapping lookup to get the target user name. Mapping lookup information would include:► Source user: VE console user’s long name

► Source registry: VE console registry (found using VeSourceSystem alias)

► Target registry: registry associated with host and port.

– If SSO registry type is SYSTEM, then it is the registry with an alias of VeDnsHostName=<target host name>

– If SSO registry type is APPLICATION, then it is the registry with an alias of VeApplication=<target host name>:<target port>

► Additional information: additional information found in the GCR for the given target host name, target application ID, and target port.

– A lookup will be done using each version of additional information that is found, starting with <host name>:<app id>:<port>, then <host name>:<app id>, and then <host name>. If no mapping is found, then a lookup will be done without any additional information.

31


JAAS Mapping Module

If the authentication method = USER► Retrieves the cached password for the target user.

► The mapping lookup will return the target user ID and password. This information is returned to the JCA connector.

If the authentication method = IDENTITY_CONTEXT► An Authentication Context is created that contains all of the source and target

application information, as well as the pre-mapped target user ID.

► The Authentication Context is then stored in the IMR, and an Identity Context Reference to the Authentication Context is created. This is an 8-byte string that identifies the Authentication Context that it references.

► The following credential information is returned to the JCA connector:

– User ID = **CTXREF

– Password = Identity Context Reference

32


Identity Context Reference Processing

Server side processing► Pluggable Authentication Module (PAM) provides a mechanism to authenticate users using

different methods than user ID and password.

– PAM technology is only supported on AIX/Linux. VE SSO has provided a PAM implementation for AIX/Linux that is used by IBM Director.

– IBM Director has written Java equivalent code for Windows and i5.

– PAM processing:

● Checks if the passed User ID starts with ‘**’. If not, it just returns.● IBM Director server is running outside of WAS and may be on a system

without any VE environment setup. Therefore, it does not know how to get to the GCR or IMR. It uses the VESSOEnablerServlet to perform VE functions.

● Packages the Identity Context Reference (encrypts/encodes/etc.) and sends it to the servlet.

● Parses the Authentication Context returned by the servlet to determine the target user ID, and returns that to its caller (IBM Director).

Client side processing► The servlet finds the Authentication Context based on the Identity Context Reference. It

packages the Authentication Context and returns it to the caller.

33


Identity Context Reference processing

IBM Director Bridge during install calls the vessoserverconfig command script, which generates the password to be used by the PAM implementation when communicating with the VESSOEnablerServlet. The command will store the password in the GCR and will also write the password to a file. If IBM Director Server is running on a different system than the Bridge, the file needs to be copied to that system. This password is used to encrypt the data flowing between the PAM implementation and the servlet.

Since IBM Director is currently the only user of the PAM support, and they can be installed on a system outside of the VE environment, all of the PAM related support is shipped with Director. This includes:► The PAM implementation as well as code required by this support (Identity Context

code, EIM code, etc.)► The vessoclientconfig command. This command is used to update the password set

by vessoserverconfig. It will update the password in the file and then communicate the password change to the servlet.– Note that for AIX/Linux, this command makes use of the CURL support to

communicate with the servlet. This support is not available on Windows or i5. For those platforms, the command produces a string that needs to be pasted into a browser window, which then sends the request to the servlet.

34


Debugging Identity Context Ref Support

The following instructions are for Linux and AIX only. ► The PAM implementation (pam_ve.so) uses the syslog capability for both AIX and

Linux.

– Administrators for these operating systems need to ensure syslog has been enabled on their system. If not, they should consult the appropriate documentation for enabling this capability.

► Once syslog has be enabled, the following must be done to get messages from the PAM implementation.

– On Linux:● In /etc/syslog.conf the following line can be added. This will log all messages

to the log file /var/log/allmessages.♦ *.* -/var/log/allmessages

– On AIX:● In /etc/syslog.conf the following line can be added. This will log all messages

to the log file /var/log/allmessages.♦ *.debug /tmp/syslog.out

35


Debugging Identity Context Ref support (cont…) In /var/VE/vessoclientinfo.cfg the following information is kept:

► PAMVERSION=1.0

► SERVLETS=http://lp04ut4:10460/VESSO/VESSOEnablerServlet

► CLIENTID=N0VZVEFHOEk=

► HOSTID=webster.austin.ibm.com

PAMVERSION – Version of VE supported by the PAM implemenation.► PAM was not supported in VE Release 1

► An undocumented feature is the ability to add a “D” to the version (PAMVERSION=1.0D), which allows for extended debugging. Extended debugging will cause the PAM implementation and the servlet to write additional debug information.

SERVLETS – where to access the servlet that resolves the ID context reference into an authentication context. There may be multiple URLs here separated by “;”s.

CLIENTID – Communication between the PAM implementation and the servlet are encrypted. The ID stored here is a base64 encoded representation of the key.

HOSTID – Host where the PAM implementation resides, passed to the servlet. If the CLIENTID value gets out of synch between the vessoclientinfo.cfg file on the system

and the servlet, the best option is to delete the file and rerun the vessoserverconfig command for the system.

36


Debugging Identity Context Ref support (cont…)

Example of PAM SYSLOG… with extended debugging enabled

37


Debugging Identity Context Ref support (cont…)

Example of VESSOEnablerServlet logging with extended debugging enabled

Detailed SSO Configuration Information

39


GCR SSO Configuration Information

VE Settings Category: CMR► Keys:

– LDAPHost

– LDAPPort

– SSOBaseDN

– EIMDomain

– LdapAdminId

– EimUrl► Usage:

– Set and retrieved be common runtime install.

– Set and retrieved by SSO GUI.

– Retrieved by SSO utilities.

40



VE Settings Category: veSecurity► Keys:

– veAutocreateIMRObj

– veIMRInstall► Usage:

– Set and retrieved be common runtime install.

– Set and retrieved by SSO GUI.

– Retrieved by SSO utilities.

41


GCR SSO Configuration Information VE Settings Category: veSecurity

► Keys:

– ClientConfigInfoA:hostname– ClientConfigInfoB:hostname

► Usage:

– Contains the encrypted IMR password and password used to communicate with VESSOEnablerServlet.

– Common runtime will set and retrieve the IMR password.– SSO GUI will set and retrieve IMR password.– SSO utilities will retrieve IMR password.– vessoserverconfig command will set the

VESSOEnablerServlet password.– vessoclientconfig command will reset the

VESSOEnablerServlet password.– VESSOEnablerServlet will set and retrieve its password.

42


GCR SSO Configuration Information VE Settings Category: SSOConfig

► Keys:

– CFGTGT_VERSION_● Version for the default app info. If a new version on install, then

all target default info will be added again.

– CFGTGT:<appid>● Value: AUTH_MECH=<authMech>,REG_TYPE=<regType>

– CFGSRC_VERSION_● Version for the default app info. If a new version on install, then

all source default info will be added again.

– CFGSRC:<appid>● Value: AUTONOMIC=<Y or N>

► Usage:

– Initially set during common runtime install.– Can be reset, removed, or viewed by the vessoconfig

command.

43



VE Settings Category: SSOConfig► Keys:

– CFG:<appid>:<hostname>● Value: AUTH_MECH=<authMech>,REG_TYPE=<regType>

► Usage:

– Configuration information for each application instance.

– Set during suite installer by applications that call the SSO ISX bean.

– Set for RDS during RDS configuration.

– Set for EWLM during Domain Manager configuration.

– Can be set, removed, or viewed by the vessoconfig command.

44



VE Settings Category: SSOConfig► Keys:

– ADDLINFO:<hostname>:<appid>:<port>

– ADDLINFO:<hostname>:<appid>

– ADDLINFO:<hostname>● Value: <additional information>

► Usage:

– Set for RDS during RDS configuration.

– Can be set, removed, or viewed by the vessoconfig command.

45


IMR SSO Configuration Information

EIM Registries► All EIM registries that will participate in Single Signon must be configured

for SSO. All configured registries will have special SSO aliases added to them. SSO will never use the name to find the registry. One of the aliases will always be used to find a particular registry.

► Source registries

– 1 registry for the VE Console users– 1 registry for autonomic applications

► Target registries

– A target registry will be created the first time an application is configured to use the host. There are two types of SSO target registries:

● System● Application

46



VE Console Source Registry

► Only 1 source registry for VE Console users per VE environment. May have already been created by Management Central (VE R1). If registry is found then new alias is added.

► Created during Common Runtime install (if it does not exist)

– Registry name: VEC_SOURCE_<environment name>

► Registry alias added

– Alias type: VeSourceSystem– Alias value: VEC_SOURCE_<environment name>

► During SSO mapping lookup, registry is found using the VeSourceSystem alias

47


IMR SSO Configuration Information VE Console Identifier

► Each VE Console user will require an EIM Identifier. There may already be an EIM identifier for this user if one had been set up for Management Central. First check to see if this user has a source association between the VE Console user and the VE Console registry.

► Created during SSO GUI processing (if it does not exist)

– Identifier name: VEC_<user’s short name>_<environment name>

VE Console Source Association► Identifier: Identifier just created.

► Source registry: VE console registry

► Source user: User’s long name

– VE Security code will be passed the user’s short name. Security will retrieve the WAS security information to build the long name.

– For example:

● shortName: tdalton● longName:

cn=tdalton,cn=users,dc=dpetty3,dc=rchland,dc=ibm,dc=com

48



VE Autonomic Source Registry

► Only 1 source registry for VE Console users per VE environment.

► Created during Common Runtime install

– Registry name: VEC_SOURCE_AUTO_<environment name>

► Registry alias added

– Alias type: VeSourceSystem– Alias value: VEC_SOURCE_AUTO_<environment name>

► During SSO mapping lookup, registry is found using the VeSourceSystem alias

49



VE Autonomic Identifier► For each autonomic application an EIM Identifier will be created. Currently,

the only autonomic application is RDS.

► Created during Common Runtime install (could be from SSO GUI in the future)

– Identifier name: VEC_<source application ID>_<environment name>

VE Console Source Association► Identifier: Identifier just created.

► Source registry: VE autonomic registry

► Source user: Source application ID

► Created during Common Runtime install

50


IMR SSO Configuration Information Target Registries

► A target registry will be created when it is first configured for SSO. The target registry is configured for SSO:

– When a target application is registered to run on a host system. Currently, this registration occurs at 4 different occasions:

● When called by the suite installer post-install processing● EWLM special processing. The EWLM target application registry

is created. ● RDS special processing. RDS configures the target applications

it will be connecting to.● The SSO GUI.

– Use of the vessoconfig command► Before a registry is created, we will check to see if the registry already

exists.

– First check for EIM registry with alias type of LdapDnsHostName.– Next check for EIM registry with alias type of VeDnsHostName.

► Appropriate aliases are always added to each registry.

► Policy mapping lookup is enabled for all newly created registries.

51


IMR SSO Configuration Information Target System Registries

► When an application indicates it uses an SSO System registry, it indicates that they will be using the system user registry. For example: an OS400 registry.

► Aliases: Each target system registry will have 2 aliases added to it for VE SSO.

– First alias is a generic alias that is the same for all target registries. This alias is used by the SSO GUI to find all registries that are participating in VE SSO.

● Alias type: VeTargetSystem● Alias value: VEC_TARGET_<environmentname>

– Second alias is a VE DNS alias. It is the alias that is used for mapping lookup operations. It is also the name that is displayed in the GUI.

● Alias type: VeDnsHostName ● Alias value: <dns host name>

► EIM Registry Name: dns host name

► Lookup Alias: VeDnsHostName

► GUI display name: dns host name

52



Target Application Registries► With application registries, there can be more than 1 authentication registry

on a host system. So application registries are identified by both the host and port to differentiate between each registry.

► In addition, on an SSO lookup, the application may be connecting to a system that is not the system used for authentication. An example:

– Authentication system = ldapx at port 389– Connecting to system = sysx at port 23

► When configuring a target application registry, if the authentication host and port are different than the target host and port then both sets need to be provided. Otherwise, it is assumed that the authentication system and the connecting system are the same.

► EWLM is a target application that will use a target application registry. In this case, the target host and port are the same as the authentication host and port.

53


IMR SSO Configuration Information Target Application Registries

► Aliases: Each target application registry will have 3 aliases added to it for VE SSO.

– First alias is a generic alias that is the same for all target registries. This alias is used by the SSO GUI to find all registries that are participating in VE SSO.

● Alias type: VeTargetSystem● Alias value: VEC_TARGET_<environmentname>

– Second alias is a VE DNS alias. It contains the authentication host and port values. It is also the name that is displayed in the GUI.

● Alias type: VeDnsHostName ● Alias value: <authentication host name>:<authentication port>

– Third alias is also a VE DNS alias, but for the target host and port (which could be the same as the authentication host/port). It is used for the mapping lookup.

● Alias type: VeApplication ● Alias value: <target host name>:<target port>

► EIM Registry Name: <authentication host name>:<authentication port>

► Lookup Alias: VeApplication

► GUI display name: <authentication host name>:<authentication port>

54


IMR SSO Configuration Information Additional Information

► Additional information can be used on lookup operations to specialize the search. For example, when going to System XYZ, a VE Console user may need to map to a special user for Director and to a different user for Management Central. A mapping lookup operation would find both users. It would return an error indicating ambiguous results were found.

► Additional information could be used on the search to distinguish between the 2 users. To use additional information you would have to:

– Add information to the GCR that tells the mapping operation the additional information to use in the search.

– Add that additional information to the correct target user.► The additional information that is defined for the GCR can be specified 3 ways, from

most specific to least specific:– host:appid:port

● If single sign-on target information matches all 3, try this additional information

– host:appid● If single sign-on target information matches both, try this

additional information– host

● If single sign-on target information matches host, try this additional information

55



Additional Information► A mapping lookup operation will try each additional information string that it

finds in the GCR looking for a target user. If nothing is found them a final search will be done with no additional information.

► The vessoconfig command can be used to add and remove additional information from the GCR as well as a target user.

► Please note: Information in the GCR only indicates additional information to use in the lookup. It does not add it to any target user. The additional information would have to be added to the target user separately.

► Please note: If you map to multiple target users, you will need to add additional information to all of them. A lookup specifying null for additional information will always find all of the target users.

56


NoticesProduced in the United States of America, 08/04, All Rights Reserved

IBM, IBM eServer logo, IBM logo, e-business on demand, DB2, DB2 Connect, DB2 Universal Database, HiperSockets, Enterprise Storage Server, Performance Toolkit for VM, Tivoli, TotalStorage, VM/ESA, WebSphere, z/OS, z/VM and zSeries are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both.

Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Intel is a trademark of Intel Corporation in the United States, other countries or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, Windows and Windows NT are registered trademarks of Microsoft Corporation

Other company, product and service names may be trademarks or service marks of others.

57


Notices – cont’d

Information concerning non-IBM products was obtained from the suppliers of their products or their published announcements. Questions on the capabilities of the non-IBM products should be addressed with the suppliers.

IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply.

IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area.

All statements regarding IBM’s future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.

Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios

58


End Of Presentation

ibm confidential | january 2005 presentation subtitle: 20pt arial regular, teal r045 | g182 | b179...

Documents

pt arial regular

white indications

white maximum length

pt arial bold

white ibm logo

maximum text length

line information

white template release