Skip to content. | Skip to navigation

Sections
Personal tools
You are here: Home Accelerate Articles Understanding the SB+ or SB/XA Security API

Understanding the SB+ or SB/XA Security API

In the past, accessing SB+ or SB/XA for UniData and UniVerse security from outside of SB security screens was difficult. But now, you can use a new function, SH.SEC.API, to talk to SB+ or SB/XA security using subroutine calls when outside of the SB security screens. Beginning with SB+ 5.4.0 and SB/XA 6.0.0, it makes it significantly easier for the system administrator to maintain SB security. This article teaches you how to implement this API and includes detailed programming examples.

Maintain SB+ or SB/XA security for UniData & UniVerse servers without using the security screens

Level: Intermediate

Brian Kupzyk ( bkupzyk@rs.com), Support Engineer, Rocket Software

29 Mar 2007 - Updated 19 May 2010


Introduction

System Builder (SB+) and System Builder Extensible Architecture (SB/XA) are cross-platform, rapid application development and deployment environments that enable developers to focus on what they know best: their application, their business, and their users. SB+ or SB/XA lets you quickly design UniData or UniVerse data server structures and develop applications using a comprehensive developer interface.

Both SB+ and SB/XA provide comprehensive security systems. It is possible to define users and user groups within a hierarchy of parent-child relationships while logged in to SB+ or SB/XA; however, this is only possible when using the SB security screens. Any attempt to amend or create SB+ or SB/XA user or group security records outside of SB configuration screens results in both a security violation and security record corruption. However, SB+ 5.4.0 and SB/XA 6.0.0 implents a security API subroutine called SH.SEC.API for applications developed in SB+ or SB/XA. This API integrates the settings in the application with SB+ or SB/XA user and group security, thus enabling users with appropriate permissions to update SB user and group security records from outside of SB configuration screens. Additional checks for SB/XA user security fields were added at SB/XA 6.0.2.

This article teaches you how to use the SH.SEC.API function to access, control, and manage SB+ or SB/XA security when outside of the SB security setup screens using BASIC programs. The code segments below are for example purposes only. In the real world, these routines would be used from a custom input screen or via a mass update program, such as changing a printer reference in all user records.

As of SB+ 5.4.1 and SB/XA 6.0.0, there are 12 available options that can be passed through PARAM (in other words, the subroutine call includes 12 options), as described in the following table:

Table 1. The 12 available options for SH.SEC.API

PARAM Function
1 Create user record
2 Amend user record
3 Delete user record
4-10 Reserved
11 Create group record
12 Amend group record
13 Delete group record
15 Retrieve all restricted account access for a group
16 Retrieve all unrestricted account access for a group
17 Retrieve allowed processes
18 Retrieve disallowed processes
19 Retrieve allowed menu options
20 Retrieve disallowed menu options

Programming Details

Before showing the examples of how to use the SH.SEC.API security subroutine, some programming details will be noted here.

To enable the use of the SH.SEC.API subroutine, the following is required:

  1. The user initiating this program must be in the SB+ or SB/XA ROOT group.
  2. The SB.CONTROL <15,16> control flag must be set to a value of 1 or 2 before the subroutine will execute. The available options for this SB.CONTROL flag are:
    • 0 - Not Enabled - No Subroutine call
    • 1 - Enabled (Recommended) - An SB+ or SB/XA message is sent to all of the other ROOT group members informing them of this change. This message contains details about the subroutine execution including which user ran the security API, the date/time it was run and from what IP address.
    • 2 - Enabled (Not Recommended) - No SB+ or SB/XA message will be sent. This is not a recommended value for this setting, since it removes tracking notification.
    • Process Name - Custom process to be called to handle user notification.

  3. To set this flag, edit the DMCONT file and the SB.CONTROL record, or set the value through a BASIC program. 

Programming Recommendations:

  • We recommend that you back up your DMSECURITY file before testing this routine.
  • Before making calls to the SH.SEC.API routine, SB+ COMMON must be initialized.
  • Prior to calling the SH.SEC.API, set the minimum values as follows: Function type = PARAM; User records = VALUE; Group records = KEY
  • When using the PARAM options related to groups, attribute 3 of the record can only be blank if the group ID is equal to "ROOT".
  • To adhere to SB+ or SB/XA standard conventions, you should use uppercase user IDs and group IDs. The developer is responsible for this validation, as well as any information that goes into the record.
  • When running any SH.SEC.API parameters in a program to amend security, the API respects record locking. This means the record cannot be opened in SB+ or SB/XA security setup screens while the API program is trying to amend the same record. In this case, a record locked message is displayed.

 

Back to top

Examples of the Available API Options

To help you build a customized interface, we provide you with the user record definition layout that SB+ or SB/XA expect. As a developer you are responsible for all field validation within your customized user and group security screens. For your convenience, the complete user and group definition layouts are included at the end of this document. Links are provided below:

These attributes are the minimum requirements for creating a new user record: 1-5, 10, 15, 16, 21, 27 (including all multi-values), and 28.

PARAM 1: Create a new user record in the SB+ or SB/XA security API

The following BASIC program uses the SH.SEC.API to create a new user ID in SB+ or SB/XA based on a record from another file. The idea is to collect all the relevant information needed to create a new SB+ or SB/XA user ID using a customized interface, and then storing that information on a file that the program can access. 

Note: You will need to check that the user ID doesn't exist before trying to create it; otherwise, it will overwrite the existing record. The example below shows a method of checking for an existing user. 

These steps are necessary to successfully test the following example:

  1. Create a file and call it SEC.FILE.
  2. Copy a user record, that is "~MYUSER", from DMSECURITY to the new file. The commands are:
    • COPY DMSECURITY "~MYUSER"
    • At the TO: prompt type: (SEC.FILE BASE and press Enter.
  3. Run the program example below.

This program example will create a new user called "NEWUSER" based on the record BASE from the file SEC.FILE with password XXXX. The password will be changed and encrypted after first logon with this user ID. The user will be prompted to change the password from XXXX to a new password. Use the Common parameter VALUE when modifying user records. 

PARAM 1 Example

 

           
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

OPEN "SEC.FILE" TO SEC.FILE ELSE CRT "OPEN SEC.FILE ERROR"; STOP
IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

READ SEC.FILE.REC FROM SEC.FILE,"BASE" ELSE SEC.FILE.REC = ""

IF SEC.FILE.REC THEN
  PARAM = 1; *New User
  VALUE = "~NEWUSER"
  * Check that record doesn't exist before adding user (F.PASS = DMSECURITY)
  READ DMSECURITY.REC FROM F.PASS, VALUE ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     RECORD = SEC.FILE.REC
     * Call Security API (record ID is VALUE field above)
     CALL SH.SEC.API 
     IF RTN.FLAG THEN CRT "Unsuccessful" ELSE CRT "Successful"
    END ELSE
     CRT VALUE:" user already exists, use PARAM = 2 to update." 
  END
END

  

PARAM 2: Amend an existing user record in the SB+ or SB/XA security API

This example uses the user created in the PARAM 1 example above. 

Note: The user record must exist and must have no null flags. Validation will fail and you will not be able to amend an existing user record if any of the user flags are not set. 

PARAM 2 Example

 

       
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 2; * Amend User
  VALUE = "~NEWUSER"
  * Check that record exists before amending user
  READ DMSECURITY.REC FROM F.PASS, VALUE ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT VALUE:" user doesn't exist, use PARAM = 1 to create." 
    END ELSE
     RECORD = DMSECURITY.REC
     RECORD<3> = "MYFIRSTNAME"; *First Name
     * Call Security API (record ID is VALUE field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN CRT "Unsuccessful" ELSE CRT "Successful"
  END

 PARAM 3: Delete a user record from SB+ or SB/XA security

This example uses the user created in the PARAM 1 example above.

 

PARAM 3 Example

 

           
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 3; * Delete User
  VALUE = "~NEWUSER"
  * Check that record exists before amending user
  READ DMSECURITY.REC FROM F.PASS, VALUE ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT VALUE:" user doesn't exist, can not be deleted." 
    END ELSE
     * Call Security API (record ID is VALUE field above)
     RECORD = DMSECURITY.REC
     CALL SH.SEC.API
     IF RTN.FLAG THEN CRT "Unsuccessful" ELSE CRT "Successful"
  END

  

PARAM 11: Create a new SB+ or SB/XA group record

The minimum requirement for creating a new SB+ or SB/XA group is a record with the first three attributes defined:

  1. Type = "G"
  2. Description
  3. Parent Group Code

These attributes are described in detail in Table 3: Group Definition Record Layout, found at the end of this document.

The following steps are necessary to test the next example:

  1. Create a file and call it SEC.FILE.
  2. Copy a group record, that is 'MYGROUP' from DMSECURITY to the new file. The commands are:
    • COPY DMSECURITY "MYGROUP"
    • At the TO: prompt type: (SEC.FILE MYGROUP and press Enter.
  3. Run the program example below.

Use the Common parameter KEY when modifying group records.

This example uses the group 'MYGROUP' as a base for the new group ID 'NEWGRP'. It then changes the description, sets the 'ROOT' group as its parent group, and clears the list of users in the group.

 

PARAM 11 Example

 

           
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

OPEN "SEC.FILE" TO SEC.FILE ELSE CRT "OPEN SEC.FILE ERROR"; STOP
IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

READ SEC.FILE.REC FROM SEC.FILE,"MYGROUP" ELSE SEC.FILE.REC = ""

IF SEC.FILE.REC THEN
  PARAM = 11; *New Group
  KEY = "NEWGRP"
  * Check that record doesn't exist before adding group (F.PASS = DMSECURITY)
  READ DMSECURITY.REC FROM F.PASS, VALUE ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     RECORD = SEC.FILE.REC
     * Set password and force change on next login
     RECORD<2> = "NEW TEST GROUP";* Description
     RECORD<3> = "ROOT";*Parent Group, can't be blank unless KEY is 'ROOT'
     RECORD<14> = ""; *Clear list of users in the group
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN CRT "Unsuccessful" ELSE CRT "Successful"
    END ELSE
     CRT VALUE:" group already exists, use PARAM = 12 to update." 
  END
END

  

PARAM 12: Amend an existing SB+ or SB/XA group record

This example uses the group created in the PARAM 11 example above.

 

PARAM 12 Example

 

$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 12; * Amend Group
  KEY = "NEWGRP"
  * Check that record exists before amending group
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, use PARAM = 11 to create." 
    END ELSE
     RECORD = DMSECURITY.REC
     RECORD<2> = "NEW TEST GROUP DESCRIPTION"; *Group Description
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN CRT "Unsuccessful" ELSE CRT "Successful"
  END

  

PARAM 13: Delete an existing group record

This example uses the group created in the PARAM 11 example above.

 

PARAM 13 Example

 

           
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 13; * Delete Group
  KEY = "NEWGRP"
  * Check that record exists before deleting group
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not be deleted." 
    END ELSE
     RECORD = DMSECURITY.REC
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN CRT "Unsuccessful" ELSE CRT "Successful" 
  END

  

PARAM 15 Example - Retrieve all restricted account access for a group

 

$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 15; * List restricted access for a group
  KEY = "NEWGRP"
  * Check that the record exists first
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not get details." 
    END ELSE
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN 
         CRT "Unsuccessful" 
        END ELSE 
         CRT "Successful"
         CRT "Value: ":VALUE
     END
  END

  

PARAM 16 Example - Retrieve all unrestricted account access for a group

 

$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 16; * List unrestricted access for a group
  KEY = "NEWGRP"
  * Check that the record exists first
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not get details." 
    END ELSE
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN 
         CRT "Unsuccessful" 
        END ELSE 
         CRT "Successful"
         CRT "Value: ":VALUE
     END
  END

  

PARAM 17 Example - Retrieve allowed processes

 

$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 17; * Retrieve allowed processes for a group
  KEY = "NEWGRP"
  * Check that the record exists first
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not get details." 
    END ELSE
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN 
         CRT "Unsuccessful" 
        END ELSE 
         CRT "Successful"
         CRT "Value: ":VALUE
     END
  END

 

 

PARAM 18 Example - Retrieve disallowed processes

 

$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 18; * Retrieve disallowed processes for a group
  KEY = "NEWGRP"
  * Check that the record exists first
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not get details." 
    END ELSE
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN 
         CRT "Unsuccessful" 
        END ELSE 
         CRT "Successful"
         CRT "Value: ":VALUE
     END
  END

  

PARAM 19 Example - Retrieve allowed menu options

 

       
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 19; * Retrieve allowed menu options for a group
  KEY = "NEWGRP"
  * Check that the record exists first
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not get details." 
    END ELSE
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN 
         CRT "Unsuccessful" 
        END ELSE 
         CRT "Successful"
         CRT "Value: ":VALUE
     END
  END

  

PARAM 20 Example - Retrieve disallowed menu options

 

       
$INCLUDE DMSKELCODE COMMON
$INCLUDE DMSKELCODE STANDARD.EQU

IF SB.CONT = 0 THEN 
   CRT "SB+ COMMON must be initialized first.";STOP
END

  PARAM = 20; * Retrieve disallowed menu options for a group
  KEY = "NEWGRP"
  * Check that the record exists first
  READ DMSECURITY.REC FROM F.PASS, KEY ELSE DMSECURITY.REC = ""
  IF DMSECURITY.REC = "" THEN
     CRT KEY:" group doesn't exist, can not get details." 
    END ELSE
     * Call Security API (record ID is KEY field above)
     CALL SH.SEC.API
     IF RTN.FLAG THEN 
         CRT "Unsuccessful" 
        END ELSE 
         CRT "Successful"
         CRT "Value: ":VALUE
     END
  END

 

Back to top

Table 2. User Definition Record Layout

 

AMC.VMC Description
0 User ID (2 to 8 Alpha)
1 Type = "U"
2 Surname
3 First Name
4 Password (Encrypted)
5 Group Code (4 Alpha)
6 Start Menu (Sys-ID,MenuName,Opt-No.)
7 Start Menus' Account
8.MC Last Maintained By (Audit on this record))
9.MD Last Maintained Date " " " "
10 User Status Code (Active,Logged,Misc,Resigned,Network,Developer)
11.M Old Used Passwords
12 Password Rollover Date
13 Alt ID Code/User Code (For Address lookup etc)
14 Checksum
15 Keyboard Lock (Mins)
16 User defined Macro Lead-in Character
17.MC User defined Macro Switch Character
18.MD User defined Macro Switch Character
19.MC Switch Chars (no vm - generated)
20.MD Macro Exec strings (generated from 18)
21 Short Name/Nick-Name for Office use, friendlier status
22 Field Access Code
23 Diary Access Code
24.M LOG-ID KEY
25 Message Flag (If Present)
26.1 Machine ID (Used in Networked machines)
26.2 Global machine user (1 = yes)
27.MC Flags for user key insertion
27.1 Full Refresh Of Whole Screen (N/Y)
27.2 Auto Help Display (N/Y/M/A)
27.3 Suppress Confirm On Screen Esc (N/Y)
27.4 Command Stack Per Account (N/Y)
27.5 Suppress Beep On Error (N/Y)
27.6 Auto Extend Field Length (N/Y/D)
27.7 Suppress Logon Message Delay (N/Y/M/A)
27.8 Show errors in dialog box (N/Y)
27.9 Main Heading Justification (C=0/L=1/R=2)
27.10 GUI User preferences - Add Fkey ref. to buttons
27.11 GUI User preferences - Center all screens
27.12 GUI User preferences - Center all menus (1,3,4)
27.13 GUI User preferences - Center/position help
27.14 GUI User preferences - Center/position lookups
27.15 GUI User preferences - Generate GUI screen code
27.16 GUI User preferences - Grey Out Disabled Forms
27.17 GUI User preferences - Deselect before Int. Help
27.18 ECLType 'U' (N/Y)
27.19 Disable 1st Level Help (use HELP_STRING)
27.20 Suppress E19 (derived fld/conv) in FD tool (N/Y)
27.21 Use "sbplistlistviewclass" for GUI Selects
27.22 GUI User preferences - Menu Navigation Method
27.23 GUI User preferences - Self-Contained Forms Flag
27.24 Disable SBClient Tooltips
27.25 Use Windows Edit Menu (GUI Click)
27.26 Language Code
27.27 Temporary Quiet Mode Flag
27.28 Date format - International or American
27.29 New password next login (N/Y)
27.30 Autologin Flag (0,1,2)
27.31 Validate Send ESC to server on X from Mainwin
28.MD Flags in attribute 27 converted (N=0,Y=1,D=2,M=2,A=3)
29.M Terminal ID(s)
30.M Printer ID(s)
31.M Aux Printer ID(s)
32.1 User Process (instead of CHAINing SB.SYSMENU)
33.MC SBX Branches
33.1 Tools Branch (Y=Disabled/Removed)
33.2 Help Branch (Y=Disabled/Removed)
33.3 Readme Branch (Y=Disabled/Removed)
33.4 Multiple System IDs (Y=multiple in Menu Only Mode)
35 OA group for message grouping
36 User is IN / Out (0/1)
37.M Outgoing message
38.1 Print Select Flag (N, Y, RO)
38.2 Aux Print Select Flag (N, Y, W)
39.M Print Defaults (Name\Stat\Assign\Copies)
40.M Auxiliary Print Defaults (Name\Stat)
41-60 Reserved
61.1 Not Used (SB/XA Only)
61.2 Show Terminal Window (SB/XA Only)
61.3 Show Debug Window (SB/XA Only)
62.MC System ID for Theme (from 63.M)(SB/XA Only)
63.MD Theme to use in given system ID (from 62.M) (SB/XA Only)
64.1 Navigation Style for Windows (SB/XA Only)
64.2 Navigation Style for Browser (SB/XA Only)
65.1 Windows ID (SB/XA Only)
65.2 Not Used (SB/XA Only)
65.3 Not Used (SB/XA Only)
65.4 Local Storeage of User IDs and Passwords (SB/XA Only)
66.M Applications (SB/XA Only)
67.M OS User ID (SB/XA Only)
68.M OS Password (Encrypted) (SB/XA Only)
69.M SB User ID (SB/XA Only)
70.M SB Password (Encrypted) (SB/XA Only)>

 

Abbreviations: M - Multi-Value; C - Controlling; D - Dependent

Note: This information was last updated in April 2010. Refer to the SB+ or SB/XA documentation set for any future updates.

 

Table 3. Group Definition Record Layout

 

 

AMC.VMC Description
0 Group Code (Alpha)
1 Type = "G"
2 Description
3 Parent Group Code
4.MC Child Group Codes
5.MC Accounts Un-Restricted List
6.MC Restricted Accounts List
7 Inhibit Break Key (Y/N)
8 Inhibit Supervisor (Y/N)
9 Inhibit Process From Inputs (N/C/A)
10 Inhibit TCL (Y/N)
11 Keyboard Lock Upper Limit (Mins)
12.1 Allow or Disallow Verbs list (A/D)
12.MC Restricted Verbs
13.MC Valid Report Locations
14.MC Users of this Group
15.MC Active Dates OR Days (Start Date or Day of Week)
16.MD Active Dates OR Days (Upto Date or Day of Week)
17.MD Active Logon From Times
18.MD Active Logon Upto Times
19 Password Rollover Date Expression
20 Check-Sum
21.MC Last Maintained by
22.MD Last Maintained Date
23.M Is <12.M> not blank (Y/N)
25.M Unrestricted Accounts up Tree
26.M Restricted Accounts up Tree
27.M Restricted Verbs Up Tree
28.M Restricted Files Up Tree
29.M Group Printer Defaults
30.M Group Aux Print Defaults
31.M Default User Flags
33.M Work field for Default User Flags
38.1/38.2 Printer Flags (Default User Flags)

Abbreviations: M - Multi-Value; C - Controlling; D - Dependent

Note: This information was last updated in April 2010. Refer to the SB+ or SB/XA documentation set for any future updates.

Back to top

Conclusion

In this article, we provided you with an explanation of the new SB+ or SB/XA security API, along with descriptions of the 12 options available in the API and examples of each option. We also explored the background of the SB+ and SB/XA security APIs and the power they give you, as the developer, to customize your own security front end to communicate with SB security. You should now be able to take this information and use it to enable the SB+ or SB/XA security API in your environment.

 

About the author

Brian Kupzyk is a Rocket U2 support engineer that has over 10 years of support experience with SB+ and SBXA. He has a Bachelor of Science degree in Information Systems from Metropolitan State College of Denver, and a Master of Science degree in Information Systems from University of Colorado at Denver.

 

Document Actions