PAS for OpenEdge recommends implementing SAML with an SP-initiated flow.

How SAML works in PAS for OpenEdge

A SAML workflow that involves PAS for OpenEdge is similar to any SP-initiated SSO workflow:
  1. A user tries to access a resource or service hosted by the service provider, PAS for OpenEdge. Typically, this request is a browser-based user request.
  2. PAS for OpenEdge, internally redirects the resource request to the identity provider for authentication before allowing the service to be accessed based on oeablSecurity.properties settings.
  3. PAS for OpenEdge sends a form submit with a SAML request to the identity provider.
  4. The identity provider requests credentials from the user. Typically, the security challenge is in the form of a login screen.
  5. If the identity provider is able to authenticate the user, it sends a SAML response containing a SAML assertion to PAS for OpenEdge.
  6. PAS for OpenEdge receives the SAML response and validates the SAML assertion. If the assertion validation is successful, PAS for OpenEdge grants access to the requested service or resource by processing the SAML assertion based on properties configured in its oeablSecurity.properties file. It performs tasks such as:
    1. Decryption: If the assertion is encrypted or signed, the PAS for OpenEdge web application uses the identity provider's public key (exposed using the provider's metadata) to decrypt the message.
    2. Validity Period Check: PAS for OpenEdge verifies that the assertion is not past its expiration date.
    3. First Level HTTP Method Validation: The PAS for OpenEdge web application checks if the HTTP method used by the PAS client to send the SAML assertion is a permitted method.
    4. Authorization: The PAS for OpenEdge web application obtains the user's roles from attribute statements in the SAML assertion. It matches these roles with the roles defined for resource URLs in the

      oeablSecurity.csv file to determine if the user is authorized to access the requested resource.

    5. Second level HTTP method validation: The PAS for OpenEdge web application checks if the HTTP method used in the request matches the permitted HTTP method defined for the requested resource URL in the oeablSecurity.csv file.
    6. CLIENT-PRINCIPAL Creation: If the PAS for OpenEdge web application is able to perform the previous tasks successfully, it creates a sealed CLIENT-PRINCIPAL object and passes it to the relevant ABL resource.
    7. Response: Finally, the PAS for OpenEdge web application sends a response to the client application.
  7. The client application processes the response and grants access to the end-user, to perform the operation.

How SAML assertion elements map to CLIENT-PRINCIPAL object attributes

If the PAS for OpenEdge web application is able to validate the SAML assertion, it creates a sealed CLIENT-PRINCIPAL object and passes it to the required ABL resource.

The following attributes of the resulting CLIENT-PRINCIPAL object are populated from the SAML assertion's fields:

CLIENT-PRINCIPAL attribute SAML assertion field
USER-ID1 NameID1
DOMAIN-NAME1 NameID1
ROLES2 Optional attributes for roles 2
SESSION-ID SessionIndex attribute in AuthnStatement
LOGIN-EXPIRATION-TIMESTAMP Checks for a value in the following order:
  1. SessionNotOnOrAfter in the AuthnStatement section identifies when a user's session expires.
  2. NotOnOrAfter in the Conditions section identifies when the token expires.
  3. OEClientPrincipalFilter.expires in the oeablSecurity.properties represents an offset from NOW to create an expiration timestamp. If it is zero, then there is no expiration date.

1 If the NameID is an email address, PAS for OpenEdge uses the '@' separator to extract the user ID and the domain name.

2 The names of these optional attributes must be set in the samlToken.UserDetails.roleAttrName property in the oeablSecurity.properties file.

Other attribute values are populated based on the OEClientPrincipalFilter properties set in the oeablSecurity.properties file.

If you want to set other attributes, that are not covered by either the SAML assertion or the default OEClientPrincipalFilter, then you can set them using any of the 10 key-value OEClientPrincipalFilter static properties. For example, if you want to set the DOMAIN-DESCRIPTION attribute, then you can modify a key-value property, as follows:

OEClientPrincipalFilter.properties.1.key=DOMAIN-DESCRIPTION
OEClientPrincipalFilter.properties.1.value=OEApplication

Logout

PAS for OpenEdge supports the SAML logout model allowing logout requests from PAS for OpenEdge to the IdP to log out user.

  1. User sends a logout request.
  2. PAS for OpenEdge, the service provider (SP), generates a signed logout token.
  3. PAS for OpenEdge sends the logout token to the identity provider (IdP).
  4. Identity provider validates the logout token.
  5. Identity provider logouts the user and generates a logout result token, (successful or unsuccessful).
  6. Identity provider sends the logout result token to PAS for OpenEdge.
  7. PAS for OpenEdge validates and processes the logout result token.
    1. If the logout is successful, PAS for OpenEdge clears the current session and if a logout URL is defined, the user is redirected to the logout URL. If no logout URL is defined, a logout message is displayed.
    2. If the logout is unsuccessful, PAS for OpenEdge redirects the user to the default error page.
    The oeablSecurity.properties file includes the following SAML logout properties:
    Table 1. Logout properties
    Property Description
    samlLogout.request.uri=/saml2/logout SAML logout request URI.
    samlLogout.success.url= (Optional) Successful logout redirect URL.
    samlLogout.success.message=Logout executed Successful logout message, if logout redirect URL is not set this is displayed.
    samlLogout.idp.result.uri=/saml2/logout/result Identity provider supplied URI to send logout result token.
    samlLogout.keystore.path=${catalina.base}/ablapps/ ${oeabl.ablapp.name}/conf/${oeabl.ablapp.name}.p12 Path to keystore to store SAML logout token signature key.
    samlLogout.keystore.type=PKCS12 Keystore type matches the type defined in the samlLogout.keystore.path.
    samlLogout.keystore.password=oeph0::76E5F6C

    162276768465F02E4D2D1DDCD

    Password for the keystore.

    samlLogout.request.signature.key=defsigkey

    Key alias used to sign SAML logout token.
Note: The values are formatted to fit in the table.