TIVOLI ACCESS MANAGER FOR ENTERPRISE SINGLE SIGN ON (ESSO)(ADVANCED ACCESSPROFILING)UNIT THREEAuthor: Sharad Ganesh/New York/IBM
Pre-requisites and goals • Pre-requisite for taking this Unit • Taken the Tivoli Access Manager for ESSO powered by Encentuate basic training and the Advanced AccessProfiling Unit One & Two modules. • Using the methodologies in Unit One, you should be able to write the correct signature for applications, windows, controls, web elements etc. • Understand the concept of a workflow engine (aka state engine) modeled in an AccessProfile. • Understand how to write an AccessProfile to model the application workflow of interest using the available triggers. • Familiar with the trigger match mechanism and how the state transition happens mirroring the application workflow of interest. • Unit Three goals • Single Sign On (SSO) capture, auto-fill and save actions • Standard workflow automation actions • Understanding what you can do with the data transfer action • Graceful logoff for application(s) • What can you do with AccessAgent plug-ins? (Plug-ins as actions) • Actions for constraining user access
Agenda (Topics covered) • Recap of the state engine/workflow engine execution model • Understanding the concept of an action by example • SSO actions • State transition • Concept of an action and workflow automation • Actions for workflow automation • Actions to set a property value • Actions to transfer data from a property or string literals to a window, control, input field and vice versa. • Understanding what you can do with the data transfer action • Plugins as actions • Hands on exercises
Recap of the state engine/workflow engine execution model • An AccessProfile models the application workflow of interest. This workflow diagram for an application is known as a state engine or workflow engine. • The AccessProfile encapsulates: • Events in the application workflow you want to monitor. • What actions (if any) you want to perform when each of those events is received. • We will now review how you can go ahead and understand picking actions to use for workflow automation, that includes single sign-on, change password, sign-off etc.
Understanding the concept of an action by example • AccessProfile
What is an action? • “An action or a set of actions” automates repetitive operations (entering username, password, log on, log off etc.) on the user’s behalf instead of having the user do them manually every single time. • Example: • Clicking a button • Capture and playback a user’s credential when an application’s log on screen is seen • Keystroke automation • Actions are executed on a trigger match • When a trigger matches successfully, actions under the trigger are executed in order. • Actions are executed sequentially. • Actions can result in generation of events that can then match triggers in the watch list. • Before the actions start executing, the triggers in the next state of the matched trigger are already added to the watch list. (Note: actions can generate events)
Capture and save credentials (Account data) for SSO • Concept • User credentials entered in an application need to be securely captured and saved in the TAM ESSO wallet for future playback. • Considerations • The user credentials (account data) can be captured from a single screen or across multiple screens. • Typically username, password etc. will be on the same page/screen • Many cases where username is on one screen and the password on a different screen. • The process of collecting the credentials is termed as ‘Capture’ • The process of actually storing the collected credentials (‘Capture’) to the user’s TAM ESSO wallet is termed as ‘Save’. (Note: distinction between capture and save) • Three things you need to know for Capture • Account data template • Authentication service (Auth info) • Account data bag (account data bag identified by an ID) • One thing you need to know for Save • Account data bag (account data bag ID)
Capture and save credentials (Account data) for SSO continued • Account data template (Components of a credential) • A credential consists of identification information entered by the user to log on. • Components of a credential typically are: • Username, Password • Username, Password, domain • Password only (think VNC) • Username, password & third field etc. • Authentication service (Auth info) IS THE [Verification entity] • Account data is validated against a “verification entity” • Account data is stored for a “verification entity”. • Account data must know the verfication entity • Many applications can have the same “verification entity” • Example: • Lotus Notes Email application, Lotus Sametime messenger use the same verification entity. • Yahoo Mail, Yahoo messenger, Yahoo groups use the same “verification entity” • Many applications can use the domain credentials and the enterprise domain can be the “verification entity” • Account data (credential) stored in TAM ESSO wallet by “Authentication service” name. • One entry in your TAM ESSO wallet per authentication service. • Account data bag [Name=value pair Account data bag id = account data] • Container for account data and authentication identified by a name.
Authentication service for capture (ID, name) • Identifying the authentication service is MANDATORY for account data capture. • Two types of authentication service for capture • Direct auth info. • The exact authentication service can be determined and created when writing the AccessProfile. i.e. authentication service is constant and does not change. • Authentication service is identified by an ID and a name (that will be seen on the TAM ESSO wallet) when the credential for this auth service is captured. • Account data can use this direct auth info from the auth info. dropdown. • Under Policies in AccessStudio, you can make this an enterprise auth service • Indirect auth info. • Authentication service can be determined from some field in the application. • Authentication service changes depending on what the user enters or selects. • Example: Domain name is the authentication service in Windows. It can be determined only from the domain drop-down. You cannot hardcode the domain name in the AccessProfile, because user can select what domain they want to log on to. • Example: The environment name could be the authentication service, whose value can be determined from the webpage. The user could pick an environment to log on to. • Indirect authentication services are by default captured as a personal authentication service for a user.
Authentication service for capture (ID, name) continued • Indirect auth info • Unlike direct auth info, which is pre-defined and specified in your AccessProfile, an indirect auth service is captured at run time when the application is launched. • Indirect auth service by default is captured as a personal authentication service for each user. • Authentication service match mechanism • Direct auth info. – No match required since the direct auth. Info is already specified in the AccessProfile in the Capture action. • Indirect auth info. • Auth info string is captured from the application • Goes through all the authentication services in the system and check if the “Auth info string” matches the string under “Server locators for Capture” under each authentication service. • If match is found, credential is captured under that authentication service. • If no match is found, this indirect auth info string is captured as a personal authentication service for each user, with name = Auth info. String captured from the application. • Server locators aliases for an authentication service indirect auth info strings
Authentication service for capture (ID, name) continued • Indirect auth info as enterprise authentication service • Create a New Authentication Service from AccessStudio with an ID and a name that you would like to see on the user’s wallet. • Add the strings that will be captured through the indirect auth info to the Server Locators -> Server locators to be used for injection and capture. • Under Policies, check “This is an enterprise authentication service” to make it an enterprise authentication service. • Let’s look at this from AccessStudio
Authentication service groups • When do I need to use authentication service groups? • Application can use more than one authentication service • No way to determine which authentication service to use from a list of authentication services. • Use case: Many domains to which user can log on. At the log on screen, user might have to select a domain or enter the domain field. So, the authentication service cannot be determined until the user actually enters/selects the one to be used. • Used in a Capture and Auto-fill (Inject) action • How is it used? • Capture credential • In a “captures user credentials” action if you want to add the authentication service captured to a group(s), just add the Authentication service group(s) you want to link this captured authentication service to. • Link is established during capture between authentication service and the group(s). This link can be manually established from AccessStudio. • Auto-fill credential • In a “Auto-fills user credentials” action, you can specify a list of group(s) from which you want the credentials to be fetched. • The credential along with the actual authentication service name will appear in the dialog box chooser from which the user can select the credential to inject. • Both the credentials and the authentication service field (auth_moniker) can be injected using injection fields
Authentication service groups continued Authentication service group Authentication service group Authentication service1 Authentication service3 Authentication service2
Account data • Account data template • Determine what your account data (credential) consists of to decide on the account data template to use when you capture credentials. • The items in the account data are known as account data items. • Each account data item can be: • Key field – Mandatory item in the credential. (Distinguishing identifier in a credential) • Non key field – Non mandatory item (can be empty) in the credential • Secret field (item with pwd) – Password (secret) item in the credential. (non-key field) • Non-secret field – Regular non password item in the credential • Case sensitive – Item is case sensitive (abc different from Abc) • Case insensitive – Item is not case sensitive (abc, Abc, ABC are all treated the same) • Available account data templates • adt_ciuser_cspwd (default) -
Account data templates (Choose depending on what the credential contains) • adt_ciuser_cspwd(default) [ 2 fields ] • Case insensitive username (key) and case sensitive password (secret) • adt_csuser_cspwd [ 2 fields ] • Case sensitive username (key) and case sensitive password (secret) • adt_ciuser_cisecondkey_cspwd [ 3 fields ] • Case insensitive user (key), case insensitive second field (key), case sensitive password (secret) • Example: • Username, database and password • Username, social sec # and password • Username, environment and password • adt_cipwd [ 1 field ] • adt_cspwd [ 1 field ] • adt_ciuser [ 1 field ] • adt_csuser [ 1 field ]
Account data templates continued • adt_ciuser_cipwd [ 2 fields ] • adt_ciuser_cisecondkey_cipwd [ 3 fields ] • adt_ciuser_cisecondkey_cspwd [ 3 fields ] • adt_csuser_cssecondkey_cspwd [ 3 fields ] • adt_csuser_cisecondkey_cspwd [ 3 fields ] • adt_ciuser_cspwd_cipwd2 [ 3 fields ] • adt_ciuser_cipwd_cipwd2[ 3 fields ] • adt_ciuser_cspwd_cspwd2 [ 3 fields ] • adt_csuser_cspwd_cspwd2 [ 3 fields ] • adt_ciuser_cisecondkey_cspwd_cspwd2 [ 4 fields ]
Account data bag • The contents of the credential (account data) that contains the account data items, authentication service information is contained in a virtual bag identified by an identifier. • Account data bag ID – a name to identify the account data bag. A name for the bag that contains the account data • The account data bag is analogous to a property ID value pair, where the value is not a string but the entire “account data object and authentication service blob” • Local bag (default - within the life of the application) versus global bag (accessible even after the application is closed and by other applications) • The idea of capture is to fill the bag with the value for account data items and authentication service. • Once you fill the bag with the values, bag is ready to be saved to the wallet. • The value of key fields and auth info CANNOT be empty. • Account data bag is complete only when all the items in the bag are captured and filled in by the AccessProfile. • An incomplete account data bag cannot be saved to the TAM ESSO user wallet.
Capture account data • Two things to capture • Auth info. • Pick direct auth info. • Capture indirect auth info. • Capture account data items • Capture items identified by the account data template used. • Items are known as Capture fields
Capture account data – Auth info • Direct auth info • Just pick the direct auth info for your account data. • Create one from AccessStudio, if it does not exist and pick that from the dropdown. • Indirect auth info based on where it is found • Windows application • Extract current value from a window (window title) or a control inside a window identified by a window signature • Extract current value from a dropdown (combo-box) box inside a window identified by a window signature. • Extract from windows list box inside a window identified by a signature. • Use selected item – Get value of the currently selected item in the list box • Extract from windows list control inside a window identified by a signature • Use selected item: • Column number: Column number from which value is to be extracted. • Java application • Extract current value from a java window (java window title) or a java control inside a java window identified by a Java signature (jwnd)
Capture account data – Auth info continued • Terminal emulator or mainframe application • Extract current value from the output on the emulator screen. • Starting line, ending line: Line boundary on the screen. Can be same value if you know the exact line • Starting column, Ending column: Column boundary on the screen. Can be same value if you know the exact column • From a webpage – “Web domain as authentication service” • Automatically uses the domain name as the authentication service. • The domain in the URL is used as the authentication service in auth info. • Windows/terminal emulator/mainframe application • Extract current keyboard input collected on a window, control inside a window, emulator window. • Some controls inside a window do not let you extract the value from them. • For these controls if you want to extract what the user has typed inside a control, you can use this auth info. • If auth info. is typed by the user using the keyboard and the control does not support extraction, you can use this. • Keyboard input should be collected by the “When a key is pressed on a window” trigger or the “start collecting keyboard input” action for the control.
Capture account data – Auth info continued • Using part of the extracted string in the indirect auth info • Regex to extract server locator • Use a regular expression to use only a part of the extracted string • Put a parenthesis around what you want to use from the extracted string • Make sure you escape the special characters in your regex. • Example 1: • Extracted string: firstname.lastname@example.org • Regex to extract server locator .*@(.*) • Extracted text = us.ibm.com • Example 2: • Extracted string: Connected to ibm.com • Regex to extract server locator Connected to (.*) • Extracted text = ibm.com • Example 3: • Extracted string: User johnsmith’s log on to us.ibm.com’s authentication server • Regex to extract server locator: User .* log on to (.*)'s authentication server • Extracted text = us.ibm.com
Capture account data – Auth info continued (Advanced Options) • Empty account data bag first • Yes (default) – • Clear all the existing values of the account data items and auth info in the bag. • If the bag is being used for the first time, then anyway there would be nothing inside it. • No • Do not clear the values in the bag. Used when you want to capture the values from different screens, web pages. In each screen you will fill some of the values, but still let the other values in the bag intact. • Capture account data in parts. Username on one screen, password on a different screen etc. • Used when you have multiple capture actions to fill the same account data bag incrementally as and when you have account data available for capture. • Typically in mainframe applications, emulators, you will need to capture in multiple steps in multiple capture actions. • Use local bag • Yes (default) – Valid and accessible only inside the instance of the application AccessProfile. Cannot be accessed outside this application. • No – Global bag => this account data bag can be accessed globally by other applications or other instances of the same application. • Default account data template • Pick the account data template you want to use for this capture action. The bag will then be created and initialized with the account data items accordingly.
Capture and Injection fields (Account data item field signature) • Individual account data field from/to which you want to capture or inject • Used under “Auto-fills user credentials” and “Captures user credentials” • Each field (account data item) points to a control (window, control, java control, web element, emulator screen, keyboard input) from/to which you want to capture or inject. • If all the fields (in the account data) you want to capture exist on one screen, you can group all the fields, with each field pointing to a control, element on a webpage or emulator screen. • Each field (account data item) you want to capture should be an item in the account data template that you selected for the “Capture user credentials” action. • Fields (One capture/injection field per account data item) • Windows control: Extract value of the control inside a window. Value extracted directly from the control. Uses the gettext Windows API • Windows control (Using keyboard input): Currently keyboard collected input for control inside a window. [Used when gettext not supported and in emulators] • Windows combo-box control: Extract currently selected value in dropdown • Windows list-box control: Extract currently selected value in windows list-box • Windows list-view control: Extract from windows list control inside a window identified by a signature. Specify column number from which value is to be extracted.
Capture and Injection fields (Account data item field signature) • Fields continued • Java application/Control inside a Java application/applet • Extract current value from a java window (java window title) or a java control inside a java window identified by a Java signature (jwnd) • From a webpage • Signature of the HTML element on the web page. • Things to note • Key fields in the account data cannot be empty • Authentication service (auth info) cannot be empty • Windows control versus Window control (using keyboard input) • Some window based controls will need to use keyboard input collection for extracting the value • In terminal emulators and mainframe applications, the Windows control (keyboard input) is used to capture username, password and any other user input. • In an emulator or mainframe application, you need to capture the input from the emulator window (black window) inside the main window. The keyboard input is actually directed to the inner (black background) window and not the main application window in most cases.
Capture and Injection from/to fields fails? • Extraction fails (Value extracted is empty) • Auto-fill field fails (Nothing is injected into the field) • Extraction of only a part of the string from a field fails
Hands on exercise • Capture from different applications • Change account data template. • Illustrate the use of different account data templates • Demonstrate incremental capture
Auto-fill/inject account data • Auto-fill • Auth info. (needed to identify what credential(s) to fetch) • Pick direct auth info. • Indirect auth info. • Authentication service group • Auto-fill account data items (Injection fields) – [What to inject] • Auto-fill/inject items identified from the account data bag • Items are known as Injection fields
Auto-fill/inject account data • “Auto-fills user credentials action” • Fetches account data for the specified authentication service from the user wallet. • This action is responsible for fetching account data into an account data bag identified by an ID • Three use cases after request for account data for an authentication service: • No account data • One account data • More than one account data • Auto-fill • Injection/auto-fill of the fetched account data is done through Injection fields • “Auto-fills user credentials action” with no Injection fields will not inject anything. It can be used to ONLY fetch account data into the account data bag. • Basic Options • Account data bag id • Injection fields • Authentication service info • Credential search fields • Random password fields
Auto-fill/inject account data – Basic Options • Account data bag id • Account data bag into which the account data is fetched. • If more than one account data is found for an authentication service, the account data that the user selects from the list, is put into the account data bag identified by the id. Until the selection happens, the account data bag is empty. If user clicks ‘Cancel’, account data bag is empty. • If no account data is found, the account data bag has nothing (empty) • Injection fields (One field for each account data item to be auto-filled) • Same as capture fields described under “Capture and Injection fields (Account data item field signature)” • Authentication service info • Direct auth info • Same as “Capture account data – Auth info” • Indirect auth info • Same as “Capture account data – Auth info” • Direct Auth Group Info • Add a group or a list of groups to search under for account data. All account data under the authentication services in the group will be fetched. • Fetch all account data under the group(s) specified.
Auto-fill/inject account data – Basic Options continued • Credential search fields • Used when some item(s) of the account data is already pre-filled at the time of fetching the account data. • Example: Username is already pre-filled or pre-selected on the application. So you want to only fetch account data corresponding to the authentication service and the pre-filled username • This is basically used as a filter to narrow down the account data to fetch, since you already know one of the fields. (e.g. username is pre-filled or pre-selected) • You can specify one or more known fields. Typically only one field is known and it is most likely the username (pre-filled).
Auto-fill/inject account data – Basic Options continued • Random password fields • Same as “Injection fields” but has an additional option to generate a new random password • Generate new secret = Yes – generates a new random password for this account data item. Works in conjunction with the policies on the server: • 1. Under a user’s profile -> Authentication service Policies ->Enable manual password change with random password? – Set it to Yes • 2. Under Authentication service Policies -> Under Password Policies you can set the random password generation rules for type of random password. • Generate new secret = No (default) – does not generate a random password, but uses the random password previously generated for this account data bag • Advanced Options • Fetch account data from wallet • Yes (default) – Fetches account data from user wallet into the account data bag. • No – Does not fetch account data, but just uses the existing account data in the bag that is already fetched. Does not show the credential chooser dialog (if injection policy is set to Ask) • Empty account data bag first • Yes (default) - Empty the account data bag in the bag before fetching account data from the user wallet for the authentication service. • Use local bag • Account data bag containing account data is local and valid only for this application.
Auto-fill/inject account data – Options continued • Signature of window under which injection happens • When the injection policy is set to Ask, the log on chooser dialog is shown under this window. • The log on chooser dialog should be shown with respect to a window for windows based application. • The signature is the window with respect to which the log on chooser should be displayed to the user. • If the window with respect to which it is to be shown is not found, then it is shown with respect to the desktop. • A valid main window should be specified to make sure the log on chooser is shown appropriately. • For web applications (websites) the browser window is used as the default. • Override injection policy • Injection policy that overrides the injection policy set in the TAM ESSO user wallet. • Do not override (default): Use the one in the TAM ESSO wallet • Auto-fill: no dialog prompt. Automatic log on after auto-fill. (As long as only one credential is found) • Always: auto-fills credentials but does not auto log on. (As long as one credential is found) • Ask: Prompt the log on chooser dialog for the user to select credential(s) • Never: Do not auto-fill or auto log on. No SSO for the authentication service/application.
Hands on exercise • Use the auto-fill user credentials action • Illustrate different ways you can use the auto-fills action • Fetch credentials • Use pre-fetched credentials in the account data bag
Save captured account data (credential) to wallet (Saves user credentials) • What does this do? • Saves the account data in the account data capture bag to the user wallet • Saves the contents of an account data bag (credential) identified by an id to the user wallet • When can you use this action? • Account data bag (identified by the account data bag id) must be full. i.e. the account data bag items and the authentication service info must be filled in with the appropriate values • After you have captured account data you can: • Save immediately – without waiting to make sure if the credentials (account data) was correct • Save on a successful log on – wait for a indication (event) to make sure the captured credential is correct • Anything that needs to be saved to the user wallet – Could be during log on or change password where you will save the account data bag containing the new password. • Basic Options • Account data bag id: Account data bag ID contents to be saved to the user wallet • Advanced Options • Signature of the window under which save dialog shows • Window under which Save dialog should appear for Windows, mainframe & Java applications. • For save actions on a web page, it will automatically use the main browser window
Save captured account data (credential) to wallet (Saves user credentials) continued • Things to note when using the Save action • Note: • Do not use this under a “When a left mouse button is clicked on a window” or “When a key/keys are pressed on a window or web element”, since it pops up a dialog that could potentially cause conflict. • Resolution: • If you want to save credentials/account data under this action, add another state with either a “Fires immediately” or a “Fires after a specified time” with a time out of 0.001 as the time out value” trigger. Add the action under whichever trigger you use. • If policy for the Enterprise authentication service (“Prompt user on auto-capture of password” = No) is set to not popup a save dialog, then you do not need to use a separate state and trigger. You can in such cases, just use the save action under any trigger. Only the dialog causes the conflict, so when there is no dialog, you do not need to use the resolution.
Why does Save action fail – Nothing saved? • Authentication service is empty • Authentication service is either not specified or is empty • If indirect authentication service is specified, maybe it is captured incorrectly or is empty • Key field is empty • If even one key field in the account data template is empty, save action will fail. • Example • Username (aditi_ciuser) is empty in a adt_ciuser_cspwd • Key field item is not captured before performing the save action • Account data bag is invalid/empty • Account data bag is not defined or is empty at the time of using the save action. • Is Save for Personal authentication services disabled? • Under AccessAdmin -> System Policies -> Wallet Policies, check the value of • Enable automatic sign-on for personal authentication services? • User signed on to TAM ESSO AccessAgent and SSO enabled? • Check the TAM ESSO AccessAgent icon and make sure ‘SSO is not disabled’.
Actions for workflow automation on the user interface • Automation on a window or control inside a window • Clicks a window (Win32) • Simulates keyboard input • Closes a window (Win32) • Sets the check-box state (Win32) • Automation on a web page and elements on a web page • Clicks a web element (Web) • Automation on a Java applet and Java applications • Clicks a window (Java) • Automation actions on all application types • Automates data input (auto fill data) • Automation actions on a window or a control inside a window • Clicks a menu option
Non-user interface actions • General • Wait for some time • Start installing BHO for embedded IE browser (Win32) • Stop installing BHO for embedded IE browser (Win32) • Audit logs • Adds an entry to the audit log • Adds a custom entry to the audit log • Policy related • Changes the auto-fill policy • For collecting keyboard input • Start collecting keyboard input • Stop collecting keyboard input • Graceful logoff related • Notifies AccessAgent of application logoff
Actions for compliance and modifying application behavior • Window or a control inside a window • Closes a window (Win32) • Sets the visibility of the window (Win32) • Disable or enable the window (Win32) • Disable or enable the menu item (Win32) Web page and elements on a web page • Sets the visibility of the Web element (Web) • Disable or enable the Web element (Web) • General • Kill a process
Actions for workflow automation on the user interface • Automation on a window or control inside a window • Clicks a window (Win32) • Click a button, control or a window • Bring a window to the foreground • Bring keyboard focus to a control or window • Click on a window at a specific point • Basic Options • Signature of window, control to identify the control to click on • Simulate click using windows messages • No (default): Click is simulated without using the mouse by sending a Windows message. Typically works on dialogs with @class_name=#32770 • Yes: Left-click using the mouse. Similar to use using the mouse and clicking on the control, window. Works on all controls, windows inside a window. • X-Pos and Y-Pos: For owner drawn applications when you are not able to exactly identify the control to click on, you can use X-Pos and Y-Pos to identify the point on the window that has the control you want to click on. • Make sure position does not change due to screen resolution • Position to click on in a window where your control is, but cannot be identified
Actions for workflow automation on the user interface continued • Simulates keyboard input • All keyboard input simulation can be done using this action • Keyboard automation for all keys/key combinations on your keyboard • Used to perform auto logon on emulators, windows, java applications or for navigation across fields in an owner drawn application window. • Basic Options • Signature of window keys need to be sent: Window, control inside a window to which keyboard input is directed. Be sure the window to which the keyboard input is to be sent has keyboard focus when the keyboard input is sent. • Keys • Key to press: Select the key to press. • Repeat count: Number of times you want this key press to be done. Typically used when you use the BACKSPACE key • Click window first: • Yes (default): Click on window before the keyboard simulation • No: Do not click on the window before keyboard simulation. Used on mainframe applications, where you do not want to change the current cursor position in the application. • Closes a window (Win32): Closes a window. Equivalent to clicking Cancel or clicking ‘X’ on the top right corner
Actions for workflow automation on the user interface continued • Sets the check-box state (Win32) • Signature of the checkbox • Set the check-box state • Checked (default) • Unchecked • Automation on a web page and elements on a web page • Clicks a web element (Web): Clicks on a web element like a hyperlink, image etc. • Used to perform auto-logon on web sites after credential injection • Automation on a Java applet and Java applications • Clicks a window (Java): Click a button on a Java application or Java applet. The only difference between this click and a normal Windows click is the use of Java signature (jwnd)
Actions for workflow automation on the user interface continued • Automates data input (auto fill data) [“Transfers data from and to specified items”] • Copy account data contents from one bag to another in a change password action • Click stream automation • Repetitive data input or repetitive data entry automation as part of workflow automation • Set/reset a property value • After log on if you want to automate a repetitive data input workflow. • Transfer the value from one UI control to another UI control. • Basic Options • From: Data source • To: Data target • Append instead of overwrite • When transferring to the target, do you want to append this value to the existing contents (if it exists) of the target or should it be overwritten? • Yes: Append (append to the existing target value) • No: Do not append. Just overwrite existing target value (if present).
Non user interface actions • General • Wait for some time • Action to pause and wait before executing the next action • Start installing BHO for embedded IE browser (Win32) • To facilitate SSO into an embedded IE browser window. • SSO to browser window embedded in a Windows or emulator application. • Signature: Specify signature of the browser window. If no signature is specified, all browser windows will be monitored. • Stop installing BHO for embedded IE browser (Win32) • To stop SSO into an embedded IE browser window • Used with the above action to stop monitoring the embedded browser window for SSO. • Audit logs • Adds an entry to the audit log (Comprehensive SSO related audit log events) • Adds an entry to the TAM ESSO audit logs that can be viewed from the TAM ESSO IMS server interface. • Account data bag id: Account data bag used by the associated credential. • Event: Select from a list of available events that can be audit logged explicitly • Return code: Success or Failure of the above event occurrence can be set in the audit log.
Non user interface actions • Policy related • Changes the auto-fill policy • Changes the injection policy for an authentication service with the option of changing it only in the same application session or changing it in the user’s wallet. • Basic Options • Authentication service info • Injection policy value: Ask, Always, Never, Automatic logon, Prompt for re-login • Advanced Options • Change in wallet • No (default): Change the policy only in the current application session/instance • Yes: Change the policy value in the user’s TAM ESSO wallet. All subsequent references to the auth service will use this policy, until changed again. • Where do you use it? • To temporarily prevent an auto-logon loop after a logout, when the workflow takes you back to the log on page/screen. • On successful log on, you can add this action to change the policy • When an incorrect credential is injected along with automatic logon, it could cause a loop and lockout the account. This can be prevented by changing the policy from automatic logon to Always/Never in that session using this action. • For collecting keyboard input • Start collecting keyboard input • Collect keyboard input for a control inside a window • This action starts collecting keyboard input for a control until you use “Stop collecting keyboard input” for the same control.
Non user interface actions continued • For collecting keyboard input • Start collecting keyboard input continued • This is used to collect keyboard input across different states. • Using the “When the key is pressed trigger” will only collect keyboard input when the trigger is in the watch list. • This action can be used start collecting keyboard input for a control for the entire lifetime of the control. • Graceful logoff related • Notifies AccessAgent of application logoff • Used to notify AccessAgent that the application has completed a log off. • Application performs a set of actions for signing out within the allotted time. Upon completion, it should inform AccessAgent through this action, that it has completed sign off.
Actions for compliance and modifying application behavior • Window or a control inside a window • Closes a window (Win32): Closes a window identified by a window signature. • Sets the visibility of the window (Win32) • Hide (invisible) a control inside a window or a window. Used to hide controls that show confidential information. This can also be used to show a hidden window • Disable or enable the window (Win32) • Block all keyboard/mouse input to a control, window. Prevents the user from editing the contents of a control inside a window. • Disable or enable the menu item (Win32) • Disablea menu option. E.g. disable File->Save • Menu path – e.g. File/Save. and Signature of the window having the menu should be specified Web page and elements on a web page • Sets the visibility of the Web element (Web) • Hide a web (HTML) element like a hyperlink, input control, button on a web page. • Disable or enable the Web element (Web) • Block all keyboard/mouse input to a HTML element. • General • Kill a process: Terminate a process. If no parameter is specified, it kills the process in which AccessProfile is loaded. If a name is specified e.g. winword.exe, all instances of winword is killed