DB-19: OpenEdge® Authentication Without the _User Table

DB-19: OpenEdge® Authentication Without the _User Table
Stephen Ferguson DB-19: OpenEdge® Authentication Without the _User Table Learn how to implement application based authentication without the use of the _User table. Use OpenEdge 10's advanced user identity management features to provide secure user authentication using your applications existing user data. Note that this presentation discusses features and techniques available to the ABL developer. When using SQL based languages to connect to the database, the _User table is still a requirement. Stephen Ferguson Progress Software Progress Exchange June, Phoenix, AZ, USA

Progress Exchange 2007 10-13 June, Phoenix, AZ, USA
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Agenda Authentication in OpenEdge The authentication process Identity Management with the OpenEdge AppServer™ Configuration and deployment setup DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Why User Authentication?
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Why User Authentication? What are the user authentication challenges I can face? Compliance with Security standards & Government regulations Integrate with different authentication systems OpenEdge Auditing Why is User Authentication becoming a challenge? Application development typically is about solving business problems with technology; however, there are aspects of running a business that require 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 companies 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 DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

OpenEdge Authentication Advantages
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson OpenEdge Authentication Advantages Configurable user authentication systems Configure which to use at production site Quickly extend support to new systems Support multiple authentication systems Use OpenEdge security services OpenEdge auditing core service OpenEdge database run-time security 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 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. OpenEdge allows multiple authentication systems to be defined within the database as trustworthy, and validated against at run time. These can be changed or added to without the need to make code changes for each new domain. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson What’s the Value-Add? What value is provided by OpenEdge security features? OpenEdge run-time permission checking Database table & field permissions The ABL does not need to use _User table OpenEdge auditing core service Secure ABL, SQL, & database utility auditing User login/logout and login-sessions Faster database record auditing than triggers 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. The ABL no longer is tied to the _User table to validate user details and use run-time permission checking. NOTE that OpenEdge SQL does still require the presence of the _User table, until we are able to provide the necessary SQL extensions. As we extend the ABL to support external authentication systems we will build upon the existing framework (client-principal). 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 trigger code and it will run much faster. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

ABL Database Table and Field Permissions
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson ABL Database Table and Field Permissions Order dependent, comma separated list of account names Table and field permissions stored in the database Permission Examples Table _Can-Create _Can-Read _Can-Write _Can-Delete * Steve !Steve,* Admin Field !Group1,!Group2,* Permissions (authorization) is covered in more detail in: DB-14: OpenEdge Database Run-time Security Revealed; see that presentation for more detail. Briefly, the database Permissions table allows definition of access rights at the table level (create, read, write, delete); and also at the field level (read, write). An strength of the can-* permissions is that they are stored in the database to which they apply; with the database itself presumable behind some levels of security, this adds to the overall security of data access features. The order of the permission entries is very much order dependent, with the first connection userid that matches being applied. The userid entries are independent of _User (or any other source of user identification or authorization), and are therefore maintained independently. “*” = All user IDs are allowed access. “User” = Only user ID ‘User’ has access. “!user, *” = All user IDs have access except ‘user’; do not start a user ID name with ‘*’, it resolves to all users. Use “!” to deny access. “Group*” = User IDs that begin with “Group” have access. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

The OpenEdge User Identity Challenge
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson The OpenEdge User Identity Challenge Prior to OpenEdge 10.1A The _User table was the only trusted user-id source Almost no ABL applications use the _User table No way for ABL application to tell OpenEdge that it is a trusted authentication source No way for OpenEdge to validate that a user-id came from a trusted ABL application source Solution: allow ABL applications to become a trusted source of user authentication One of the issues with _User being the only trusted user-id sources is that almost no ABL applications use it; they implement their own authentication systems within the ABL. Prior to 10.1A, there was no way to tell OpenEdge that one’s own authentication was indeed ‘trusted’, and so no way for OpenEdge to verify that a user’s credentials do indeed come from that authentication system. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Authentication and Authorization Process
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Authentication and Authorization Process Login Credentials Client AppServer Agent Authentication Manager Process Control Authentication System User Accounts Authenticate Account Check Get Account Data Client- Principal All reputable user authentication and authorization systems will have these key components and attributes in common. We advise that the Authentication Manager is in the AppServer layer of the application. This manager encapsulates all of the work to manage client authentication, including any and all OpenEdge user authentication support. Authentication: Get the user credentials (user account name, shared-secret, additional information) from the client. These credentials should be encrypted when transporting them across the network. Based on the authentication system configured for the service interface: * Lookup the account / user-id in the trusted authentication system * Validate the “shared-secret” – this may be a simple password, or a more complex structure such as bio-metric information (finger prints, retina scans, etc) * Check the account that is being used has not been disabled (e.g. user has left the company), and has not been suspended for some reasons (e.g. is not allowed to log in during certain time periods, etc) If everything validates successfully, make a copy of the necessary user account information for use by the application and create a “Principal” object as a storage container for that account information. Inside it will be a “Login-Token”, which uniquely identifies the users’ login session. Authorization essentially consists of: Obtain the Principal Obtain the user’s access-control data using the information in the access token As the application requests the use of resources, such as business objects or database, check the user’s access controls to grant or deny access Authorization Manager Access Control Data Application Resources DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

OpenEdge Authentication Strategies
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson OpenEdge Authentication Strategies What are my choices? OpenEdge Authentication with _User Can still connect to OpenEdge database using –U –P Authenticate and set the user-id for a database connection with SETUSERID() OpenEdge Authentication without _User Custom application design & implementation Do your own thing – nothing wrong with that, so long as it is secure enough to meet your requirements. You can still use _User, especially if that is what has already been implemented in an existing application, and take advantage of run time permission checking. Nothing has been removed or changed within OpenEdge that prevents the use of _User as it has always been used; Nothing has been taken away. Or you can use the 10.1A enhancements, which allows you to define your own trusted authentication source. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

OpenEdge Authentication
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson OpenEdge Authentication Use OpenEdge CLIENT-PRINCIPAL identity extensions Use existing ABL authentication modules User login-logout and session information Single sign-on between ABL products Requires Code additions Conditional configuration and deployment setup Or you can use the new CLIENT-PRINCIPAL authentication extensions available in OpenEdge 10.1A and beyond. You can incorporate the new CLIENT-PRINCIPAL in to existing ABL application authentication modules easily, allowing you to set user attributes and properties and securely SEAL them, to prevent unauthorized tampering. If using OpenEdge Auditing, the default policies include the ability to automatically audit login/logout activities, when using Client-principal. Once sealed, and so long as applications are configured to recognise the appropriate authentication systems, it is possible to share the CLIENT-PRINCIPAL between ABL products for single sign-on. This does require some additional coding and deployment/configuration, but the changes are relatively minor, and have many advantages, as we shall see. The code additions include creating and managing the client-principal object itself, and setting the client-id for the session and database connections; and the configuration and deployment options refer to setting up the authentication system domains in the database, which is optional in that it can be coded within the application, or use can be made of domains that may already exist in the application’s current authentication modules. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Introduced in OpenEdge 10.1A
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Introduced in OpenEdge 10.1A User identity access token CLIENT-PRINCIPAL object Domain Registries Identifies trusted user authentication systems Used to validate CLIENT-PRINCIPAL object User defined or loaded from database OpenEdge session user-id Synchronizes OpenEdge DB connection user-ids We introduced a number of features in OpenEdge 10.1A that support the authentication process. The client-principal is the ABL object which securely packages up user id details; it is validated against trusted authenticated systems, as defined within the database or within the application. Also new in OpenEdge 10.1A and upwards, although less visible, is the concept of a Progress session user id. Up until OpenEdge 10.1A, there was no such thing as a session user id within the AVM; the USERID was associated only with the database connection itself. What these new features allow us to do is validate a userid against a previously identified and confirmed trusted source, for example the application, and upon successful validation, SEAL the userid and its properties in an ABL object which can be passed around the system. Used to validate CLIENT-PRINCIPAL object Originating from trusted ABL user authentication module Checks integrity of user identity data Validation uses symmetric key cryptography and HMAC technologies Contents loaded from Application code using SECURITY-POLICY object OpenEdge database tables _sec-authentication-system _sec-authentication-domain DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

The CLIENT-PRINCIPAL Object
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson The CLIENT-PRINCIPAL Object Authentication System Data CLIENT-PRINCIPAL User Account Information Domain: Application User-ID: Joshua Login-token: BW3G1&2G1836D872 Login-date: /12/07 08:15:33.12 Login-expires: 6/12/07 19: State: Login Roles: Manager App-data: Company=ABC Corp Seal: AC63Galx98wBwuuw2 Login-Session ID User Account Restrictions The Principal object is really a container for user information. It’s composition can very greatly from product to product and vendor to vendor. In the Principal you can store information such as: The name of the authentication system, we’ll call this the authentication domain The state of the user’s login-session The user’s identity A login-token that is a unique value that represents that person’s login-session Access control information such as the time of login, when they must reauthenticate and so on. The roles/user-groups the user has been granted membership in It may allow the application to transport immutable user information The data integrity seal is checked to detect tampering of the client-principal. Application Defined Data Data Integrity Seal DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

ABL CLIENT-PRINCIPAL Object
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson ABL CLIENT-PRINCIPAL Object Created and managed by ABL application Represents a single user login session Sets the current user-id for The ABL application & all database connections Individual OpenEdge database connection CLIENT-PRINCIPAL’s user-id can be used for run-time permission checking Run-time permission checking can use the CLIENT-PRINCIPAL’s user id for run time permission checking; alternatively, it can also use the _User, just as in prior versions of OpenEdge. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Load Authentication Systems
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Load Authentication Systems Modify Application Startup Code - Example Loads OpenEdge session Domain Registry Cannot use domain until locked Can only be loaded once per session SECURITY-POLICY:REGISTER-DOMAIN ( “Application”,cDomToken ) NO-ERROR. SECURITY-POLICY:LOCK-REGISTRATION() NO-ERROR. You can create domain(s) in the application code as shown above. You would want to obfuscate the domain access token in some way. The above code identifies an authentication system domain named “Application” and loads it in to the session’s domain registry; once loaded in this manner (multiple authentication system domains can be loaded), they can be used to authenticate a client-principal against (but not until the registry is locked using the LOCK-REGISTRATION method). Authentication system(s) should be loaded at the start of the session and locked; once locked, they cannot be reloaded (or additional domains loaded) in the same session. Typically you would only register/lock a single domain, although you may record details for multiple domains in the database (see later). This is less secure than loading the authentication system domains from the database (see later), since multiple operations are required (REGISTER-DOMAIN and LOCK-REGISTRATION), but is available as an option. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Load Authentication Systems Example Load from application tables FOR EACH Trusted-Auth-Domain NO-LOCK: SECURITY-POLICY:REGISTER-DOMAIN (Trusted-Auth-Domain.cDomainName, Trusted-Auth-Domain.cDomainKey, Trusted-Auth-Domain.cDomainDescr, Trusted-Auth-Domain.cDomainType) NO-ERROR. END. SECURITY-POLICY:LOCK-REGISTRATION NO-ERROR. REGISTER-DOMAIN registers an authentication domain in the application’s trusted authentication domain registry, and is used to validate CLIENT-PRINCIPAL objects during the session. Once all authentication systems have been registered, further registration must be prevented through use of the LOCK-REGISTRATION( ) method, and before a CLIENT-PRINCIPAL can be validated. The key is a character expression that specifies the key to use when validating a CLIENT-PRINCIPAL object created in this domain. Progress converts this key to UTF-8 before using it, which ensures a consistent value regardless of code page settings. Domain-description and type are optional. LOCK-REGISTRATION always returns true, even if no domains have been registered, however it will not be possible to validate CLIENT-PRINCIPALs if no domain has been registered/locked. LOAD-DOMAINS is used to loads registered authentication domains from the specified OpenEdge database into the application’s trusted authentication domain registry. Progress uses this registry to validate CLIENT-PRINCPAL objects for the application during the session. Domains may only be loaded once per session. Using this method to load registered authentication domains directly from an OpenEdge database provides more security than using the REGISTER-DOMAIN( ) and LOCK-REGISTRATION( ) methods because it automatically locks the registry. The logical name or alias of a connected database from which to load registered domains, in the form of a quoted character string or a character expression, that corresponds to a connected database, otherwise a run-time error will be generated. This is less secure than loading the authentication system domains from the database (see later), since multiple operations are required (REGISTER-DOMAIN and LOCK-REGISTRATION), but is available as an option. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Load Authentication Systems Modify Application Startup Code Configure Authentication Systems and Domains in Data Admin _sec-authentication-system _sec-authentication-domain Load session Domain Registry Can only be loaded once per session Single operation, more secure Use the Data Admin tool to specify Authentication Systems and Authentication System Types in the database itself (an alternative approach is described on the next slide). Once created, an authentication system is used to validate a CLIENT-PRINCIPAL against when it is sealed. Above is the code to explicitly load the authentication system(s) in a database, prior to their use. Using the SECURITY-POLICY handle we call method LOAD-DOMAINS to populate the session’s registry. This is a more secure way of loading authentication system domains, since it is a single operation to load (Register and Lock) the domain(s); and the database is presumably secured, making it harder to impersonate the authentication system domain. The authentication system domain(s) stored in the database would need to be stored in each database against which the client-principal is to be used. SECURITY-POLICY:LOAD-DOMAINS (“Dictdb”) NO-ERROR. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Creating a CLIENT-PRINCIPAL
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Creating a CLIENT-PRINCIPAL Application User Login Code CREATE CLIENT-PRINCIPAL hCP. /* Required user account information */ hCP:DOMAIN-TYPE = cDefDomType. hCP:DOMAIN-DESCRIPTION = cDefDomDesc. hCP:DOMAIN-NAME = cDefDomainName. hCP:USER-ID = cUserid. hCP:SESSION-ID = SUBSTRING(BASE64-ENCODE(GENERATE-UUID), , 22 ). /* Optional user account information */ ... Here we see the steps involved in creating a client-principal object, using data values that have already been established by the application. The client-principal is created, the handle to which is assigned to a HANDLE variable hCp. Attributes are then assigned to the client-principal object, both standard OpenEdge attributes (DOMAIN-TYPE, DOMAIN-NAME, etc) and user defined name/value pairs. Note also the assignment of the SESSION-ID. This should be uniquely generated for each client-principal object, and used as the key to the object, for example in any context-management system. If passing the session-id between a server back to a client, it is worth encrypting the value, or obfuscating it in some way. The example here uses a base64 encoded UUID; this syntax was introduced in 10.1A. An alternative method, if using a state-free AppServer connection, would be to use the SERVER-CONNECTION-ID attribute of the SESSION handle. The SERVER-CONNECTION-ID is assigned by the AppServer broker when an AppServer accepts a connection request from a client application. The AppServer broker and all AppServer agents use the connection ID as an identifier when they log any information associated with the connection. This same connection ID is available to the AppServer agent using the SERVER-CONNECTION-ID attribute and to the connected ABL client using the CLIENT-CONNECTION-ID attribute on the server handle connected to this AppServer. If the AppServer operating mode is state-free, this value has no meaning. Code of this type would typically be inserted into your code where you being the application’s user login (authentication) process. Each time the application attempts to log in and authenticate a user, this code will then be executed. 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. Refer to the ABL reference manual for a full description of all the CLIENT-PRINCIPAL properties. 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. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Completing the Login User Login Completion Code On successful login, start user login-session CLIENT-PRINCIPAL’s access-token becomes read-only hCP:SEAL( cDomainToken ). On failed login, invalidate user login object CLIENT-PRINCIPAL’s access-token is invalid Log to audit files when auditing enabled This step happens after the application login code determines whether the login passed or failed. SEAL indicates a successful user login – the client-principal is made ready to use. It puts the CLIENT-PRINCIPAL access-token into READ-ONLY mode so that additional roles cannot be added, the user-id cannot be changed, and the application defined properties changed. Attempts to change anything after this point, will invalidate the CLIENT-PRINCIPAL and cannot use it. Note that the operation requires the originator of the client principal, the application domain, to provide 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 supplied is the reason for the login failure. This reason is automatically recorded in audit records if it is enabled (and a supporting, active audit policy exists). In fact, both these methods will automatically audit user login success and failure if auditing is enabled. hCP:AUTHENTICATION-FAILED ( “Invalid Password” ). DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Setting the Session User-id
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Setting the Session User-id Success Login Code Set the OpenEdge session’s user-id All connected databases Setting session user-id across a single database Equivalent to SETUSERID() SECURITY-POLICY:SET-CLIENT( hCP ) NO-ERROR. The next step, after SEALing the client-principal, is to synchronize the application user and the OpenEdge current user. This code uses the SET-CLIENT() method on the security policy to set the session’s current user, and it automatically synchronizes the user in all of 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. This 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 explanation. A 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 Auditing is enabled. If you connect to a database after previously SEALing the client-principal, after connection use SET-DB-CLIENT () to set the userid for the database connection. Check the results of the SET-DB-CLIENT() function the same way that you would check SET-CLIENT; and just 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. SECURITY-POLICY:SET-DB-CLIENT ( hCP, “dbname” ) NO-ERROR. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Logging Out Logout the CLIENT-PRINCIPAL and cleanup
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Logging Out Logout the CLIENT-PRINCIPAL and cleanup Invalidate the CLIENT-PRINCIPAL hCP:LOGOUT(). SECURITY-POLICY:SET-CLIENT( ? ) NO-ERROR. DELETE OBJECT hCP. hCP = ?. The LOGOUT() method changes the state of the CLIENT-PRINCIPAL access-token to “logged out” so that it can no longer be used to represent the logged in user. You need to keep the application domain’s current user in sync with OpenEdge, so that if the application user logs out, so does the OpenEdge user, so we also invalidate the session’s user-id using SET-CLIENT(?). As good housekeeping practice, we also delete the object and reset the hCPs handle. Note that this method also automatically audits the user-logout if auditing is enabled. Clear the session user-id DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Context Management Basics
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Context Management Basics Target environment is client to stateless or statefree AppServer Each interaction is independent Maintain context between related interactions Store context between client requests in a shared data store All AppServer sessions can read and write it The context is held on the server The above is one suggested way to manage context between Client and AppServer components, where each request from the client is independent from any other request, as with stateless and state-free implementations of the AppServer. The assumption is that some context between requests is required. This context, in the form of a session-id attribute of the client-principal, is stored in a shared data store – such as an OpenEdge database - on the server, where all AppServer sessions have access. The client-principal (along with any other contextual information) is stored in the shared ‘context’ database. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Asserting the Trusted User Identity (who)
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Asserting the Trusted User Identity (who) Managing context - re-establishing identity Client Processes Application Server Login Credentials Create CLIENT-PRINCIPAL EXPORT Session-id Retrieve CLIENT-PRINCIPAL Context Data Session-id IMPORT Reset User identity Retrieve CLIENT-PRINCIPAL Logout request Session-id Context Sub-system Contains BUILDS. 1 – the Client sends login credentials to the application server’s login procedure, which authenticates the user’s details; assuming success, the AppServers login procedure will create a CLIENT-PRINCIPAL object and export it as a RAW variable to the applications context management subsystem. 2 – The AppServer login procedure returns to the client the context-id for the SEALed CLIENT-PRINCPAL.. 3 – When the client makes requests to the AppServer, it passes the context-id along with the request; the AppServer procedure uses the context-id as the key to the hCp in the context subsystem; once retrieved, the hCp is used to set the user identity before processing continues. 4 – When the client log’s out, it makes a logout-request to the AppServer, again passing the context-id sealed away with the hCp. The hCp is again imported, and then hCp:LOGOUT is performed. 5 – At the end of the AppServer session, in the shutdown procedure, the AppServer should ideally clean up after itself and purge any remaining context data recorded in the context subsystem by that AppServer. Use the a UUID for context-id (guaranteed unique); use the SERVER-CONNECTION-ID as the hCp:session-id for session managed environments, otherwise use a UUID for hCp:session-id. In a session-free environment, a major difference is that the login is more likely to be managed by the AppServers service interface, rather than a login procedure. In a session-free environment, use a UUID as a session-id, and as the key to the stored CLIENT-PRINCIPAL object in the context management system; in a session managed environment, you can use the SERVER-CONNECTION-ID attribute of the session ID. IMPORT hCp:LOGOUT Purge Application Server Shutdown DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Pushing Identity into Context
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Pushing Identity into Context Store in context using hCP:SESSION-ID Assign values IF NOT lOk THEN /* invalid or new user */ DO: ASSIGN hCP:USER-ID = pcUser hCP:DOMAIN-NAME = cDomainName hCP:SESSION-ID = SUBSTRING(BASE64-ENCODE(GENERATE-UUID),1,22). lOk = hCP:SEAL(gcDomainKey). ctx.rawCP = hCP:EXPORT-PRINCIPAL(). END. /* Now reset to current user identity */ lOk = SECURITY-POLICY:SET-CLIENT(hCP). SEAL the principal EXPORT the principal Set client does all the validation… DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Re-asserting Identity from Context
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Re-asserting Identity from Context IMPORT principal Store in context using hCP:SESSION-ID /* Re-assert identity – from context if possible */ CREATE CLIENT-PRINCIPAL hCP NO-ERROR. lOk = hCP:IMPORT-PRINCIPAL(ctx.rawCP) NO-ERROR. IF lOk AND (hCP:LOGIN-STATE <> "LOGIN":U) THEN DO: /* an invalid client-principal was imported */ END. lOk = SECURITY-POLICY:SET-CLIENT(hCP). Validate Don’t switch unless have to – pull it out of context – validate it is the correct user Set client DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Clean-up – Logging out the User
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Clean-up – Logging out the User Log out at true end of session Only do a logout when user really changes Not with each Application Server roundtrip! Log out IF VALID-HANDLE(hCP) THEN DO: IF hCP:LOGIN-STATE = "LOGIN":U THEN hcp:LOGOUT() NO-ERROR. /* also delete context using hCP:SESSION-ID */ SECURITY-POLICY:SET-CLIENT( ? ) NO-ERROR. DELETE OBJECT hCP NO-ERROR. hCP = ?. END. To maintain a sensible audit of a user’s activity, it makes sense to not log the user out at the end of each AppServer connection; the user should only be logged out at the genuine end of session for the user, i.e. when they actually call the application’s logout/close-down process. Clear the session DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Primary User Authentication APIs
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Primary User Authentication APIs LoginClient ( INPUT cUserid AS CHAR, INPUT rAuthToken AS RAW, [….,] OUTPUT cSessionId AS CHAR ). AnyProcedure ( […,] INPUT cSessionId AS CHAR). LogoutClient ( INPUT cSessionId AS CHAR ). This slide talks about what the login, logout, and remote procedures might look like in a state-free application server. Here are sample, example definitions of user login, logout, and remote procedure calls. In the Login we return the unique id that identifies the client login session, the CLIENT-PRINCIPAL’s SESSION-ID. This could be obfuscated using a variety of methods. The cSessionId, returned to the client after a successful login, would then be passed 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. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Managing CLIENT-PRINCIPAL Context
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Managing CLIENT-PRINCIPAL Context Faster to import CLIENT-PRINCIPAL from context than re-create and re-seal Be explicit about Login (SEAL) Logout Since there is no access to connect or disconnect procedures when running State-free we have to be explicit about the Login and Logout procedures. When managing context with the CLEINT-PRINCIPAL, we need to explcit about passing the user context id, i.e. the CLIENT-PRINCIPAL:SESSION-ID, back to the client (as an output parameter) to your client login procedure; and then to pass it back as an input parameter when re-establishing context with remote procedures on the AppServer. The remote procedure can then use the obtained SESSION-ID and use it to restore context for the user, as part of the client-connection context for the user. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Enabling an Existing Application
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Enabling an Existing Application Steps to enable authentication features Enable OpenEdge database features For migrated databases Set database options Create authentication system domains and domain types proutil dbname –C updateschema The primary migration tasks involve a fixed number of steps listed here, and will cover client-server and state-managed AppServer applications. Step 1 is not required on newly created OpenEdge databases. However, if the database has been migrated from an earlier version of OpenEdge, create the necessary meta-schema tables using PROUTIL dbname –C updateschema Step 2 is setting the database options appropriately, to use the application/session user id instead of the _User or default user id. Step 3 is only necessary if you wish to maintain the authentication system domains in the database and load them with LOAD-DOMAINS; you can alternatively store the authentication system details in application tables, or in the code itself. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Setting Database Options
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Setting Database Options Data Admin → Admin → Database Options 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 wish to 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 “Use Runtime permission checking” option. ( When you do use run-time permission checking, you would clear the flag that uses the application user-id for auditing.) The _db-option table is new to the 10.1A metaschema as an extension of the _db table. The dialog is split in two sections, “Auditing Options” and “Security Options”. The menu option for this dialog is disabled for databases which do not contain the _db- table, i.e. pre 10.1A databases, and the individual options are disabled if their corresponding feature does not exist, i.e. the “_aud” tables or the “_sec” tables don’t exist in the database. Auditing Options Use Application User Id for Auditing: Overrides the database connection’s userid for recording audit userid and uses the application level userid for auditing (if set). Enforce Audit Insert Privilege: Tells the OpenEdge client executable to require that users, of applications that use Application Auditing and that set Auditing Context, must be granted the Audit Inserter (_sys.audit.appevent.insert) privilege in order for auditing data to be recorded. Security Options Trust Application Domain Registry: Override’s the database connection’s domain registry settings and uses the application level domain registry settings. Disallow Blank UserId: Blocks database connection with blank UserId. Record Authenticated Client Sessions: Record user login sessions. Use Runtime Permissions Checking: Apply CAN-WRITE, CAN-READ type permissions at runtime, rather than at compile-time. DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Authentication System Domains and Types
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Authentication System Domains and Types Data Admin → Admin → Security → Authentication System Maintenance Create Authentication System Types and Authentication System Domains in the datanase DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson In Summary Define your own trusted authentication systems No longer tied to _User Extensible user authentication provides core functionality OpenEdge gives you the tools to migrate now DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

For More Information, go to…
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson For More Information, go to… PSDN Implementing the OpenEdge Reference Architecture: 8: Context Management OpenEdge Principals Progress eLearning Community: What's New In OpenEdge 10.1: Auditing Documentation: Core Business Services DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

Relevant Exchange Sessions
DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Relevant Exchange Sessions DB-8: Jump Starting Your OpenEdge Auditing Solution DB-14: OpenEdge run-time database security revealed ARCH-4: A Stateful Application in a Stateless World DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Questions? DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson Thank you for your time DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge Authentication Without the _User Table Stephen Ferguson DB-19: OpenEdge Authentication Without The _User Table Progress Exchange June, Phoenix, AZ, USA

DB-19: OpenEdge® Authentication Without the _User Table

Similar presentations

Presentation on theme: "DB-19: OpenEdge® Authentication Without the _User Table"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DB-19: OpenEdge® Authentication Without the _User Table

Similar presentations

Presentation on theme: "DB-19: OpenEdge® Authentication Without the _User Table"— Presentation transcript:

Similar presentations

About project

Feedback