It is important to note that PAS for OpenEdge does not serve as a direct-login service provider. This means that end users do not directly access a PAS for OpenEdge web application. Instead, a PAS for OpenEdge client application acts as the intermediary between the user and the PAS for OpenEdge web application. A PAS for OpenEdge client application can be any REST or JavaScript program that can send and receive HTTP messages.
The client application is also responsible for sending SAML requests to an identity provider, receiving a SAML assertion from it, and then sending the assertion to the PAS for OpenEdge web application. The assertion must be sent via the basic authentication header in an HTTP request.
To set up a PAS for OpenEdge web application as a SAML service provider, you must configure the web application's oeablSecurity.properties file.
How SAML works in PAS for OpenEdge
A SAML workflow that involves PAS for OpenEdge is similar to any Service Provider Initiated SSO workflow, but with a few additional steps:
1. A user uses a browser to connect to a PAS for OpenEdge client application and tries to perform an operation that requires a resource deployed on a PAS for OpenEdge web application.
2. The PAS for OpenEdge client application generates a SAML authentication request and redirects the user's browser to the configured identity provider's SSO URL.
3. The identity provider processes the SAML request and presents the user with an authentication challenge.
4. The user responds to the authentication challenge by supplying the required credentials.
5. The identity provider authenticates the user and generates a SAML response containing a SAML assertion and redirects the user's browser to the client application's ACS URL.
6. The PAS for OpenEdge client application receives the SAML response, processes it, and sends the SAML assertion to the PAS for OpenEdge web application by passing it in an HTTP Authorization header.
7. The PAS for OpenEdge web application processes the SAML assertion based on properties configured in its oeablSecurity.properties file. It performs tasks such as:
a. Decryption: If the assertion is encrypted and/or signed, the PAS for OpenEdge web application uses the identity provider's public key (exposed via the provider's metadata) to decrypt the message.
b. Validity Period Check: The PAS for OpenEdge web application verifies that the assertion is not past its expiry date.
c. 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.
d. ACS URL Validation (Optional): Depending on the property settings, the PAS for OpenEdge web application may also match the assertion's <AudienceRestriction> element against the PAS client's ACS URL (exposed via the client's metadata).
e. Authorization: The PAS for OpenEdge web application obtains the user's roles from attribute statements in the SAML assertion and determines if the user is authorized to access the requested resource. It does this by matching the roles obtained from the assertion with the roles defined for resource URLs in the oeablSecurity.csv file.
f. Second Level HTTP Method Validation: The PAS for OpenEdge web application verifies that the HTTP method used in the request matches the permitted HTTP method defined for the requested resource URL in the oeablSecurity.csv file.
g. 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 the object to the relevant ABL resource.
h. Response: Finally, the PAS for OpenEdge web application sends a response to the client application.
8. The client application processes the response and grants access to the end user to perform their desired 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
SESSION-ID
SessionIndex attribute in AuthnStatement
LOGIN-EXPIRATION-TIMESTAMP3
NotOnOrAfter
attribute in Conditions
ROLES2
Optional attributes for roles 2
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.
3 The oeablSecurity.properties file has a property named samlToken.webSSOProcessingFilter.responseSkew. If a value is specified for this property (in seconds), it is added to the NotOnOrAfter timestamp.
Other attribute values are populated based on the OEClientPrincipalFilter properties set in the oeablSecurity.properties file.
If there are other attributes that you want to set, that are not covered by either the SAML assertion or the default OEClientPrincipalFilter, 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, you can modify a key-value property as follows:
