This is the basic syntax, where client-principal-handle is the handle to an unsealed client-principal object and domain-access-code is typically a MAC key value (see Table 1):

Syntax

client-principal-handle:SEAL( domain-access-code )

This method operates only on an unsealed client-principal (in the INITIAL state) and attempts to seal the object in the LOGIN state if it finds a domain entry in the session domain registry whose domain name matches the client-principal DOMAIN-NAME attribute value, and whose domain access code matches the domain-access-code value passed to the method. This operation assumes that your application has already authenticated the user identity initialized in the client-principal object. However, OpenEdge has no way to verify this; it only verifies that the object is initialized properly and that there is a matching domain name and access code in the session registry. If the values match, it then seals the client-principal using the domain access code. Sealing the object with this method also generates an auditable event to start a user login session.

CAUTION: Application-performed user authentication is inherently much less secure than OpenEdge-performed user authentication. Although your application might have access to a secure source of user accounts, it is entirely responsible for secure access to those accounts and for authenticating a user identity against them. Most importantly, by sealing a client-principal with a given user identity, the application is certifying that the identity it represents is authenticated and valid, regardless if and how the application has authenticated the identity. This certification depends on direct application access to a valid domain access code, which has the potential to be hacked at least until the application seals the client-principal and destroys the value of the access code that it has used to do so. On the other hand, during OpenEdge-performed user authentication, all access to user credentials, domain access codes, and valid user accounts is managed by OpenEdge in a secure processing environment that relies on industry best practices for identity management.

Note that this function does not assign the identity sealed in the client-principal to any ABL resource. You must use the successfully sealed client-principal in a separate SSO operation that you execute using either the SET-CLIENT( ) method or the SET-DB-CLIENT function in order to validate and (if valid) assign the identity to the current ABL session and any indicated database connections established in the session.