MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10

MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10
MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10.1A and Beyond Michael Jacobs Development Architect

Agenda Why Migrate Your User Authentication OpenEdge Security Systems
OpenEdge 10.1A User-id Management Migrating to 10.1A User-id Management There are 3 points that I would like you to keep in mind for today’s session: Extensible user authentication is becoming a necessity to meet standards and regulations OpenEdge will provide you with additional functionality that your application cannot duplicate in terms of run-time security and auditing. But only when your application’s user-id is the same as OpenEdge’s In 10.1A you see the fundamental components for interfacing your application’s users with OpenEdge in both client-server and distributed applications To satisfy these 3 points, this session will cover some basic: Why you need to be concerned Some basic distributed user authentication and user-id management use-cases Show you what 10.1A has in it that you can begin using today and some relevant use-cases This presentation includes annotations with additional complementary information MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Why Migrate Your User Authentication
What are the user authentication challenges I can face? Compliance with Security standards & Government regulations Integrate with different authentication systems Single Sign-On Auditing People in the business world usually have their highest priority set of solving business problems. This is as it should be. However, there are aspects of running that business that requires security technologies and techniques be used to safeguard the business data. One of those is user authentication and why is it any more important than the others? More and more standards and regulations require stronger user authentication More and more companys will require integration into their existing user systems such as LDAP, Active Directory, Kerberos, and so forth. Single sign-on has been on the table for many years and continues to gain additional strength each year to improve user efficiency All standards and regulations will require some form of auditing, which relies very heavily on the accuracy of user identity MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Does this apply to my application? If you or your customer does business with US Medical services ( HIPAA ) Credit card processing ( CISP ) International financial ( Basil II & SOCKS ) International computing practices ( ISO ) Business in California, USA ( SB 1368 ) US & EU Governments ( FEA standard ) Peoples private data ( Graham – Leach – Bliley ) British legal system ( BIP ) Business in EU ( EU Protection Directive ) This is a good, but does it concern you. The answer is yes if you do business in any one of these areas. I’ve noted the standard or regulation for reference. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

What technologies may my application have to support? Strong user authentication systems Strong Password based systems Hardware tokens Smart Cards ( Digital Certificates ) Microsoft workstation single sign-on Single source of user authentication Federated user identities between partners I scan an security information regularly. There are some trends that are emerging or gaining more strength. Every standard, regulation and security policy is requiring strong user authentication, with strong passwords at the bottom of the acceptability list Microsoft has provided the ability for many years to perform application single sign-on based on the user’s workstation login. Authentication systems are just plain expensive to create and maintain in production. Having all applications use the same source of user accounts simplifies and reduces costs. So requirements to use single sources of user account for authentication includes things like directory services in the form of LDAP and Active Directory will be more prevalent Federated identities are coming into play. This is where a electronic trust relationship is established between a business’s user authentication system and a partners. The partner’s employee logs into their system, maintained by the partners IT shop. A standards based user-identity is then passed to the business’s authentication system, maintained by the business’s IT shop. An electronic contract checks to see if the partner issued identity is allowed and is valid. If so, it accepts the user’s login as if it were a local account. This scenario vastly simplifies the partnering process, lowers costs, and improves security. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

What do I need to change in my application? Configurable user authentication systems Configure which to use at production site Quickly extend support to new systems No application code changes required Use OpenEdge 10.1A security services OpenEdge auditing core service OpenEdge database run-time security If you now ask what is the path that I should take my application, I would point out these two things: The industry is ever increasing the ability to treat user authentication systems as just another optional plug-in module to the application. You can pre-certify support and ship multiple methods with your application, then just configure which one, or ones, to use at the installation site. Regulations will require stronger authentication systems as well as requiring auditing and built-in database table and field security. Being able to take advantage of OpenEdge’s auditing and run-time database security makes a lot of sense, so take as much advantage of the OpenEdge services as you can. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

What value is provided by OpenEdge 10.1A security features? OpenEdge auditing core service Secure ABL, SQL, & database utility auditing User login/logout and login-sessions Faster database record auditing than triggers OpenEdge run-time permission checking Database table & field permissions No, you DO NOT need to use _user table The auditing and run-time database security are larger topics, but here are a few points to give you an idea whether you want these services to be in your application’s future. With auditing you get consistent auditing. You get user login/logout and login-sessions when you migrate your code You get a range of database specific auditing aside from tables and fields And you can remove the triggger code and it will run much faster. For run-time database security, you are now putting the table and field access controls inside the database where they are applied to all client connections, not just your application’s. It’s very easy to bypass your application, so you want to ensure that those basic access controls are applied equally to every connection. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A User-id Management Migrating to 10.1A User-id Management MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.0 Database Compile-time Security
Session _User Table Accounts OpenEdge Database ABL Application ABL Run-time _User Authentication System DB Connection _User Permissions CONNECT db –U root Authenticate The OpenEdge database security only worked at compile-time and performed very basic operations: When the database was connected, or as shown here the current user-id set, the account would be looked up, the password validated and the user’s table and field permissions located. Then all of the user’s database access would be authorized. There are three problems here: The OpenEdge user accounts are very basic and have never supported what is considered in the industry as strong user authentication None of the database connection domains can interact with each other and share user accounts and logins which makes it expensive and awkward to setup and manage The user-id authorization to tables and fields occurred only at compile-time, which makes it useless for pre-compiled applications “root” : CAN-* Connection user-id Table & Field CAN-* Permissions Authorize FIND Customer … Customer Table & Field Access Control MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.0 Application Run-time Security
Session OpenEdge Database Application authentication ABL Application ABL Run-time DB Connection Application User Accounts _User Login.p Run doLogin(“fred”) Permissions Application User Privileges Authenticate These facts have resulted in most OpenEdge application developers developing their own application security by developing and supporting their own user accounts and database access controls inside the application itself. This renders the OpenEdge database security null and void. The problem is that application security has a serious flaw in today’s network world, and that is the rouge application. It’s very easy to write 4GL to bypass application security and be a rouge application. The only way you can defeat the rogue 4GL application is if you bind your compiled r-code to the database using the DBAUTHKEY feature. Application Authorization “root” : CAN-* UserAccount Bypass Authorization Privileges ViewCustomer.p If CAN-DO (“fred”) FIND Customer … Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A Security Features
Session DISCONNECT! OpenEdge Database ABL Application ABL Run-time Audit Audit Data OpenEdge Auditing Service DB Connection _User Login.p Run doLogin(“fred”) Permissions OpenEdge Run-time Access Control Authenticate When we add the 10.1A auditing and database security into the picture, we can see that there is a disconnect between OpenEdge and your application in terms of the user that OpenEdge uses to determine what to do. The user identity management is what fixes that disconnect. “root” : CAN-* UserAccount Privileges ViewCustomer.p If CAN-DO (“fred”) FIND Customer … Authorize Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A Identity Management
What is new in Release 10.1A User Identity Access Token CLIENT-PRINCIPAL handle Synchronize OpenEdge and application user-id Domain registries SECURITY-POLICY:SET-CLIENT ( ) SET-DB-CLIENT ( ) Equivalent to SETUSERID() Database hosted ABL client security options Progress session user-id Synchronizes OpenEdge DB connection user-ids Registry OpenEdge 10.1A has more flexible user-id management built into it that allows your ABL written user account system to be trusted by OpenEdge and to securely communicate that user-id to it. Therefore, from an initial entry point of “make it possible”, we have supplied a number of fundamental distributed-application identity management features. The ABL CLIENT-PRINCIPAL handle which is the OpenEdge version of a user access-token. It allows the ABL user authentication procedure to build a secure structure to hold the authenticated user-id and their account information and give it to OpenEdge. We have a Domain Registry that lives in the Progress sessions and each OpenEdge database connections. These registries allow you to configure OpenEdge to trust user-ids that are generated by the application’s r-code. We have new 4GL language that will allow you to tell the Progress session, and/or one of the OpenEdge database connections to set its current user-id based on the CLIENT-PRINCIPAL contents. When an Progress Session or database connection receives a CLIENT-PRINCIPAL to set the current user-id, it will validate that it was created by trusted r-code that is configured in its Domain registry. Only when it passes that validation will the user-id be changed. Next, we have some configuration options that support the OpenEdge database’s Domain Registry, Auditing service, and database security. First, you can configure the database’s connection to use the Progress session’s registry itself. It gives you the option of having a single place to maintain that trust-contract information that lets all of the domains work together. OpenEdge has formalized the concept of the Progress session user-id. This session user-id represents the application-wide default user-id. You can now turn on run-time database security. Rather than just the compile time security that uses the table and field permissions you can have the checking performed at run-time using the connection’s current user-id. This is the database-security that those standards and regulations. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

User Identity Access Token
“Proof of an authenticated user’s information, including the domain that authenticated them, the roles or privileges they hold, and miscellaneous user-context.” Fred App-accounts AB25DH398E23… user,admin LOGIN Logged in ABL Procedure NBFFlintstone .NETOpenClient UI.advanced=YES USER-ID DOMAIN-NAME SESSION-ID ROLES LOGIN-STATE STATE-DETAIL DOMAIN-TYPE LOGIN-HOST CLIENT-TTY <User-defined-property> I’ll talk about CLIENT-PRINCIPALS, which are really a form of user access token. This is probably a new concept to many of you. An access token is proof of a user’s identity and contains information about the user, who the authenticator was, what their roles or groups are, account information, as well as private application user context information. In OpenEdge, the CLIENT-PRINCPAL fills this role. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

CLIENT-PRINCIPAL Operations
What can a CLIENT-PRINCIPAL do for you? Automatic user login auditing SEAL ( ) [ successful login ] LOGOUT ( ) [ logout ] AUTHENTICATION-FAIL ( ) [ failed login ] Login-sessions [ Login session-id context ] Synchronize application user login With Progress session and DB connection Between multiple Progress sessions AppServer Agents Load-balanced AppServers WebSpeed Agents A CLIENT-PRINCIPAL is kind of like the keys to the kingdom. It can be transported to many different places to open doors. When you use this object, it is directly linked with auditing so that you now get login, logout, failed login, and login-sessions which can be used to distinguish between concurrent user logins. You can now do the user authentication process once, and use those results in many places. You will find that user login can be slow in many instances, so you only do it when necessary. In OpenEdge you can now login once and pass the access-token to other Progress sessions, including AppServer/WebSpeed agents and between the WebSpeed and AppServers themselves. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Session user-id Domain Registry Session Trust Configuration CLIENT- PRINCIPAL OpenEdge Database OpenEdge Database Registry System + Domain ABL Application ABL Run-time “root” “root” Session user-id sets connection user-id DB Connection _User Registry Audit session user-id Permissions Authenticate Audit Data Lets put these features into perspective. In each database connection is a Registry, which holds the configuration information that allows the connection to validate and use a user-id from an external trusted source, such as a 4GL procedure. Next the Core now has the concept of a default user-id. It has its own registry and its own current user-id. The user-id in the session can be configured to be used as the user-id recorded in auditing records instead of the default database connection’s user-id. There exists a set of user authentication system and domain tables in the OpenEdge database that provides secure storage for loading the run-time configuration used by the Registries. Last is a ABL CLIENT-PRINCIPAL domain handle that represents a successful user login operation which the application can create and pass to OpenEdge as proof of that login. If the Registry can validate that the CLIENT-PRINCIPAL has originated from a trusted source and hasn’t been changed, it will accept it and use it to set the current user-id in the session or database connection. To make it easier, the sesssion’s default user-id is connected to all of the database connections so that when the session’s user-id is set, it will push the CLIENT-PRINCPAL to each database connection to synchronize the user-id. You have to ability to control this synchronization to suit your own application’s requirements. Domain Registry “root” Audit UserAccount Privileges Authorize Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Session OpenEdge Database OpenEdge Database Registry System + Domain ABL Application ABL Run-time “root” “root” X DB Connection _User Registry Permissions Authenticate Audit Data You can also choose to manually take control of the database connection user-id by setting it directly with a client pricipal object. “root” Audit UserAccount Privileges Authorize Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Use-case Assumptions: Case 1
Existing client-server application Uses application security (tables) Connects DB using single _user account Not using OpenEdge table & field permissions Short-term migration goals Use OpenEdge auditing core service Medium-term goals Use run-time OpenEdge database security OpenEdge RA compliant application I cannot cover all of the possible application architectures that you have created over the years. Fortunately, user-identity management does not have very many implementation options. For today’s session, I’ll talk about migrating this exiting application model to user the new OpenEdge features and position it to do incremental migrations as additional features are released. The following steps will be directly usable as you migrate your client-server application to distributed and/or OpenEdge Reference Architecture forms. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A Security Configuration
Synchronize Registries Session Registry OpenEdge Database OpenEdge Database Audit session user-id System + Domain ABL Application ABL Run-time DB Connection _User Registry Permissions Authenticate Audit Data The first task in the migration process is to set the one-time static configuration in your OpenEdge database(s). The default is for the registries to operate independently just like the database connections themselves. To make it easier you can tell OpenEdge to synchronize the database connection Registries with the session so that you have a single point of configuration information and control. The next thing is that in our use-case we will be auditing the session’s user-id that is synchronized with the application’s. Audit UserAccount Privileges Authorize Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Migrate Existing Application
Step 1: Enable 10.1A Security Features Enable OpenEdge database 10.1A features Security without OpenEdge Auditing proutil db –C updateschema Security with OpenEdge Auditing vi AuditAreas.st prostrct add db AuditAreas.st proutil db –C enableauditing … Data Administration utility Admin  Security  Edit Auditing Privileges The primary migration tasks involve a fixed number of steps that we will go through here, and will cover client-server and state-managed AppServer applications. Once the primary is done, there are some additional incremental steps for Stateless AppServer, WebSpeed, and the OpenEdge Reference Architecture State-free applications. Step number 1 involves doing a static, one-time, setup of features and options to match your application. You first need a 10.0 database, and then migrate it forward to include the new user-id management features, or to use the OpenEdge auditing service. By migrating directly to include auditing features, you get all the things necessary for user-id management. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 2: Set Client Security & Auditing Options Admin-> Database Options Audit session user-id Synchronize Registries ABL run-time permission checking To prepare a typical application for auditing, you configure the client option to record the user-id of the application which will be synchronized with the ABL session. You will typically set this option when you do not synchronize the session and database connection user-ids so that you can use the OpenEdge run-time database security. The Trust Application Domain Registry options tells OpenEdge to synchronize the database connection Registries with the session so that you have a single point of configuration information and control. For middle-term, you can choose to implement run-time database security or not by turning on the 4GL client run-time permission checking option. When you do use run-time permission checking, you would clear the flag that uses the application user-id for auditing. You want to audit the user-id from the point of table and field access-control implementation. If your table/field access controls are in your application, audit the session user-id. If your table and field access controls are handled by OpenEdge itself, then audit the database connection. Follow these rules and you will always have the user-id that is permitted access to the database data. Note: You cannot mix these and audit session user-id for application type events and the database connection user-id for database operations. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 3: Define Session-global Variables Define global session current-user storage DEF NEW GLOBAL SHARED VAR g_hCP AS HANDLE. Define global default authentication domain DEF NEW GLOBAL SHARED VAR g_cDefDomName AS CHAR. DEF NEW GLOBAL SHARED VAR g_cDefDomType AS CHAR. DEF NEW GLOBAL SHARED VAR g_cDefDomDesc AS CHAR. DEF NEW GLOBAL SHARED VAR g_cDomToken AS CHAR. ASSIGN g_cDefDomName = “OpenEdge” g_cDefDomType = “ABLApplication” g_cDefDomDesc = “Application user accounts”. ASSIGN g_cDomToken = BASE64-ENCODE(GENERATE-PBE-KEY(g_cDefDomType)). As there can be only one current user-id in an application, I declare a location to store the CLIENT-PRINCIPAL object. In preparation for handling multiple user authentication systems someday, I declare what the default user authenticaiton domain name is. In this case, I select “OpenEdge” which is the name of the domain I defined earlier. Note the obfuscation of the Domain token. I never use clear-text in my application. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A Application Initialization
Startup.p Session Registry OpenEdge Database OpenEdge Database /* Load Registries */ Connect DB … System + Domain ABL Application SETUSERID( … ) ABL Run-time X DB Connection _User SETUSERID() Locks out synchronization Registry Permissions Authenticate Audit Data Now that the static database setup has been performed, we will start with what needs to happen when the application starts. First I’m assuming that you will connect the database using a single defined user account in the database, and that user-id here is “appuser”. Next, because this use case doesn’t synchronize the database user-id with the session or application, we explicitly take control of the database connection by setting the same user-id as used in the connection. Doing this explict setting of the connection’s user-id tells the session not to Synchronize the default user-id with the connection. Last is to load the session registry. This doesn’t happen automatically because in a multiple database application we cannot know for certain which database’s tables to use. “root : CAN-*” UserAccount Audit Privileges Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 4: Modify Application Startup Code Lock database connection user-id Remove for run-time permission checking SETUSERID ( “root”, pwd, “DICTDB” ). Load Progress session Domain Registry Cannot use domain until locked Here is the code to explicitly take control of the database connection’s user-id using the SETUSERID() function. Then in the SECRURITY-POLICY handle we call a new method LOAD-DOMAINS to populate the session’s registry. SECURITY-POLICY:REGISTER-DOMAIN( “OpenEdge”, g_cDomToken ) NO-ERROR. SECURITY-POLICY:LOCK-REGISTRY() NO-ERROR. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A User Login & Logout
Session Registry OpenEdge Database Login.p OpenEdge Database (“fred”) System + Domain ABL Application ABL Run-time “fred” X DB Connection _User Registry Permissions Authenticate Audit Data Logout.p Now we migrate the application’s user login and logout operations to synchronize the application’s user-id with OpenEdge. After a successful user login, the application creates a CLIENT-PRINCIPAL object and sends it to the Progress Session. If the session registry validates it it will set the session’s user-id. When the user logs out, the application destroys the CLIENT-PRINCIPAL object. Audit “root : CAN-*” UserAccount Privileges Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

OpenEdge 10.1A User Login & Logout
Session Registry OpenEdge Database Login.p OpenEdge Database System + Domain ABL Application ABL Run-time “fred” X DB Connection _User (“fred”) Registry Permissions Authenticate Audit Data Logout.p Now we migrate the application’s user login and logout operations to synchronize the application’s user-id with OpenEdge. After a successful user login, the application creates a CLIENT-PRINCIPAL object and sends it to the Progress Session. If the session registry validates it it will set the session’s user-id. When the user logs out, the application destroys the CLIENT-PRINCIPAL object. Audit “root : CAN-*” UserAccount Privileges Customer MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 5: Modify Application User Login Code Create a CLIENT-PRINCPAL object CREATE CLIENT-PRINCIPAL g_hCP. /* Required user account information */ g_hCP:USER-ID = “fred”. g_hCP:DOMAIN-NAME = g_cDefDomName. g_hCP:SESSION-ID = SUBSTRING(BASE64-ENCODE(GENERATE-UUID), , 22 ). /* Optional user account information */ g_hCP:DOMAIN-TYPE = g_cDefDomType. g_hCP:DOMAIN-DESCRIPTION = g_cDefDomDesc. This step is inserted into your code where you being the application’s user login (authentication) process. Each time your application attempts to log in a user, this code will execute. The purpose is to create a CLIENT-PRINCIPAL object, fill it with the required login-session parameters, and add any optional properties that the application chooses to take advantage of. You should refer to your 4GL reference manual for a full description of all the CLIENT-PRINCIPAL properties. I want to note that user-login expiration is supported via the LOGIN-EXPIRATION-TIMESTAMP property, you have a formal location to carry the user’s roles, and you can add your own application defined property names. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 6: Modify User Login Completion Code On successful login, start user login-session CLIENT-PRINCIPAL’s access-token is now read-only g_hCP:SEAL( g_cDomToken ). On failed login, invalidate user login object CLIENT-PRINCIPAL’s access-token is invalid This step happens after your application’s login code has determined whether the login passed or failed. SEAL indicates a successful user login. It puts the CLIENT-PRINCIPAL access-token into READ-ONLY mode so that additional roles can be added, the user-id changed, or your application defined properties changed. If you attempt to change anything after this point, you will invalidate the CLIENT-PRINCIPAL and cannot use it. Please note that the operation requires the originator of the client principal, the application domain, to pass in the domain’s access-code. This is like a password in that OpenEdge will check this to determine that only code that knows the domain’s access-code could have issued the CLIENT-PRINCIPAL. Please hide this value in your code!! FAILED-AUTHENTICATION is exactly what it says, the user login failed. The string you supply the reason for the login failure. This reason will be recorded in audit records if it is enabled. Note, these methods will automatically audit user login success and failure if auditing is enabled. g_hCP:FAILED-AUTHENTICATION ( “Invalid Password” ). MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 7: Modify Success Login Code Set the Progress session’s user-id lStatus = SECURITY-POLICY:SET-CLIENT( g_hCP ) NO-ERROR. IF ( NOT lStatus ) THEN DO: END. After SEALing the CLIENT-PRINCIPAL you now synchronize the the application user and the OpenEdge current user. In this code I’ve used the SET-CLIENT() method on the security policy, so that when I set the Progress Session’s current user, it will automatically synchronize all of the users in the connected OpenEdge databases. SET-CLIENT () uses the domain registry to validate the CLIENT-PRINCIPAL’s access-token, so there is a possibility that it could fail for a number of reasons. That is why the CLIENT-PRINCIPAL has two properties that you use to determine what the state of the access-token is. Access tokens can be in “LOGIN”, “LOGOUT”, “FAILED”, and “EXPIRED”. The EXPIRED state indicates that you set an LOGIN-EXPIRATION-TIMESTAMP property before you SEAL’d the token, and OpenEdge has determined that the token has expired, and cannot be used. The STATE-DETAIL property will give you a friendlier explaination. A nice benefit to using this method is that when the OpenEdge database connection’s current user-id is changed, it is automatically recorded in audit records when it is enabled. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Step 8: Modify Logout Code Logout the CLIENT-PRINCIPAL and cleanup Invalidates CLIENT-PRINCIPAL g_hCP:LOGOUT(). lStatus = SECURITY-POLICY:SET-CLIENT( ? ) NO-ERROR. DELETE OBJECT g_hCP. g_hCP = ?. LOGOUT, changes the state of the CLIENT-PRINCIPAL access-token to logout so that it can no longer be used to represent the logged in user. Note here that we tell OpenEdge to invalidate the Progress session’s current user-id. You always need to keep the application domain’s current user in sync with OpenEdge. If the application user logs out, so does the OpenEdge user. When the application user logout code executes, it will also logout the CLIENT-PRINCIPAL. LOGOUT, changes the state of the CLIENT-PRINCIPAL access-token to logout so that it can no longer be used to represent the logged in user. Note here that we tell OpenEdge to invalidate the Progress session’s current user-id. You always need to keep the application domain’s current user in sync with OpenEdge. If the application user logs out, so does the OpenEdge user. Note that this method also automatically audits the user-logout if auditing is enabled. Clears session user-id MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Manually Controlling Database User-id
Lock out SECURITY-POLICY:SET-CLIENT() Equivalent to SETUSERID() Use when no _user accounts exist lStatus = SET-DB-CLIENT( g_hCP, “DICTDB” ) NO-ERROR. IF ( NOT lStatus ) THEN DO: … END. Use this in case you do not connect to the database with ANY _User account. I included this slide in case you didn’t want to use the SECURITY-POLICY:SET-CLIENT() method, and wanted to synchronize the application’s user with the database’s user manually. You check the results of the SET-DB-CLIENT() function the same way that you would check SET-CLIENT. And like SET-CLIENT, the change in the database connection’s current user-id is recorded in auditing records when it is enabled. Note also that using this function locks out SET-CLIENT(). When you choose to manage database connection user-ids manually, the automatic OpenEdge wide synchronization is disabled on that connection. This allows you to mix and match your user-id management to fit your application’s implementation. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Existing stateless AppServer™ application Uses application security Connects DB using single _user account Not using OpenEdge table & field permissions Short-term migration goals Use OpenEdge auditing core service Medium-term goals Use run-time OpenEdge database security The next migration stage to the application is to move to a stateless type of application. Same type of application, just running in a distributed form and it builds off the code we just migrated. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

User-id Management in a Stateless AppServer
Client ( CJB762B… ) AppServer Broker ( CJB762B… ) ( CJB762B… ) ( CJB762B… ) ( CJB762B… ) ABL Agent ABL Agent ABL Agent ABL Agent Session Session Session Session s All of the previous migration information is valid for all forms of OpenEdge applications. However, there are some additional steps that are needed for OpenEdge stateless and state-free application servers. In stateless application servers, each procedure can run in a different agent. When you have multiple clients this means that the agent may be running a procedure for a different client each time. Most applications have developed some type of context management to share a logged in user’s between those multiple agents. Most often, the SERVER-CONNECTION-ID that is established when a client connects to the server is used to identify the client context information for storage and retrieval. The migration steps that need to take place in stateless application servers is to synchronize the CLIENT-PRINCPAL object along with the application’s other client-connection context. User-Context ( CJB762B… ) SERVER-CONNECTION-ID MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Stateless AppServer Migration
Additional Migration steps Startup procedure: Connect to User-Context Add two fields for access-token storage Login-session-id ( CHAR, primary, unique ) Access-token ( RAW ) Empty User-Context of access-token Connect [ login ] procedure After CLIENT-PRINCIPAL:SEAL() Store CLIENT-PRINCIPAL’s access-token This is what I would do: In the startup of the application I would add two fields to my existing user context storage. At startup I would purge the system of all previous open login sessions. During the connection or login procedure, wherever you SEAL the CLIENT-PRINCIPAL object, you will now cache the object’s access-token. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Additional Migration steps - cont Activation procedure Restore CLIENT-PRINCIPAL from User-Context’s access-token ( If the SERVER-CONNECTION-ID changes ) Disconnect [ logout ] procedure After CLIENT-PRINCIPAL:LOGOUT() Delete access-token from User-Context When each procedure runs, you want to now check to see if the user is the same as the last procedure that it executed. In the stateless AppServer mode, you can use the SERVER-CONNECTION-ID attribute of the SESSION handle. If the user has changed since the last procedure execution, you need to restore the access-token from the user-context cache into the application and OpenEdge. When the disconnect or logout procedure runs, that is after the CLIENT-PRINCPAL’s LOGOUT() method is called, you remove the access-token from the user-context cache. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Caching CLIENT-PRINCIPAL Objects Storing CLIENT-PRINCPAL access-token CREATE ctx. ASSIGN ctx.Id = SESSION:SERVER-CONNECTION-ID ctx.Token = g_hCP:EXPORT-PRINCIPAL ( ). Restoring CLIENT-PRINCPAL access-token FIND ctx WHERE ctx.Id = SESSION:SERVER-CONNECTION-ID. DELETE OBJECT g_hCP. CREATE CLIENT-PRINCIPAL g_hCP g_hCP:IMPORT-PRINCIPAL ( ctx.Token ). /* SECURITY-POLICY:SET-CLIENT (g_hCP). */ In these code snippets, I’ve highlighted the two CLIENT-PRINCPAL methods to use to export the access-token and then to re-import it. The CLIENT-PRINCIPAL object has two methods whose primary purpose is for caching and transport from system to system. The EXPORT-PRINCIPAL serializes the access-token to transportable binary and stores it in a RAW variable. The IMPORT-PRINCIPAL reverses the process by deserializing a serialized access-token and inserting into the CLIENT-PRINCIPAL object, replacing the object’s previous contents. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Existing OpenEdge Reference Architecture (state-free) application Uses application security Connects DB using single _user account Not using OpenEdge table & field permissions Short-term migration goals Use OpenEdge auditing core service Medium-term goals Use run-time OpenEdge database security The last stage of migration occurs when you go to an OpenEdge Reference Architecture type of application in which the application executes procedures without any user-context handling performed by OpenEdge. Again, I’ve kept the overall application and its goals the same and builds off the stateless model we just covered. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

User-id Management in an OpenEdge RA AppServer
Client (3KU60N5TXL) AppServer Broker (3KU60N5TXL) (3KU60N5TXL) (3KU60N5TXL) (3KU60N5TXL) ABL Agent ABL Agent ABL Agent ABL Agent Session Session Session Session In state-free your application will still need to carry some concept of user-context and you will undoubtedly have a form of cache available to all the agents. However, there is no SERVER-CONNECTION-ID available from the SESSION handle. You have to provide that unique identifier yourself in your application. One thing that you can consider is using the SESSION-ID attribute of the CLIENT-PRINCIPAL. It identifies exactly one user login-session and is unique. In this case I’ll use it to illustrate the migration process. User-Context (3KU60N5TXL) SESSION-ID MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

State-free AppServer No Connect or Disconnect procedures
Additional Migration steps No Connect or Disconnect procedures Substitute Login and Logout procedures No SESSION:SERVER-CONNECTION-ID Substitute CLIENT-PRINCIPAL:SESSION-ID Pass SESSION-ID for all remote procedures Since there is no connect or disconnect in State-free, you will have to have explicit Login and Logout procedure. Substitute the stateless login and logout operations there. Next, you will have to add passing the user context id, the CLIENT-PRINCIPAL:SESSION-ID in my case, back to the client as an output parameter to your login procedure and then pass it as an input parameter to all of the remote procedures. In each remote procedure you will have to obtain the SESSION-ID and restore it as part of the client-connection context for the user. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Primary User Authentication APIs
LoginClient ( INPUT cUserid AS CHAR, INPUT rAuthToken AS RAW, INPUT cDomain AS CHAR, INPUT cSecondaryId AS CHAR, INPUT rSecondaryToken AS RAW, OUTPUT cSessionid AS CHAR ). LogoutClient ( INPUT cSessionid AS CHAR ). AnyProcedure ( …, INPUT cSessionid AS CHAR). This next slide talks about what the login, logout, and remote procedures would look like in a state-free application server. I’ve put in my definition of user login, logout, and remote procedures. In the Login I’ve returned the unique id that identifies the client login session, the CLIENT-PRINICPAL’s SESSION-ID. I then pass it as the last parameter in the remote procedures where my remote procedure performs the same type of agent context setup as the activation procedure did in the stateless model. If you are wondering about the login procedure, the one I chose to use here is what I use to allow the use of various types of user authentication systems. When logging in, you always have some user-id for the primary account name. However you may optionally have a secondary piece of information to qualify the user-id. An example of this would be the name of the company the user worked for. A good use for the secondary token would be a system that uses two passwords. The secondary token and ID may or may not be related to each other, depending upon the characteristics of the authentication system identified by the domain name. Last, the login call has a parameter for domain name. If the domain name is not supplied, the default is used. If it is supplied, then it can be used to choose which procedure to use in interfacing to the external user account system. MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

For More Information, go to…
PSDN Implementing the OpenEdge Reference Architecture: 8: Context Management OpenEdge Principals White-papers MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

In Summary Extensible user authentication provides necessary functionality Synchronizing the application’s user-id with OpenEdge can bring benefits such as core services OpenEdge 10.1A gives you the tools to begin your application’s migration now Remember those 3 points that I asked you to keep in mind for today’s session: You’ve seen more about why flexible user authentication is becoming a necessity to meet standards and regulations You’ve seen that OpenEdge now gives you the ability to share and synchronize users to make use of auditing and run-time database security By migrating you can leverage OpenEdge core services like auditing and run-time permission checking You’ve seen the basic migration steps so that you can interface your application’s users with OpenEdge in both client-server and distributed applications MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Questions? MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

Thank you for your time MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

MOVE-14: Migrating Your Authentication System to OpenEdge 10
MOVE-14: Migrating Your Authentication System to OpenEdge 10.1A and Beyond

MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10

Similar presentations

Presentation on theme: "MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10

Similar presentations

Presentation on theme: "MOVE-14: Migrating Your 4GL Authentication System to OpenEdge® 10"— Presentation transcript:

Similar presentations

About project

Feedback