Rob on EKP: Can I use an external authentication service so that users don't need to log into EKP directly?
Can I use an external authentication service so that users don't need to log into EKP directly?
In a typical organization, EKP will be one of many applications that employees or other stakeholders use on a regular basis. In this situation, it's typically desirable to provide some kind of single (or reduced) sign on, so that users don't have to perform separate logins to different applications.
EKP provides a number of mechanisms to help solve this problem. Some of those most commonly-used are listed below.
However, it's often desirable to provide an integrated authentication mechanism that will work over the internet, even if the authentication service is not physically co-located with EKP. This post describes such a mechanism.
For the sake of example, let's suppose that you are running a company portal alongside EKP, and that you want your portal users to be able to access EKP. However, you do not want users to have to log into EKP separately; rather, you want all authentication to occur via the portal, with users' identities being propagated to EKP once they have authenticated through the portal.
In order to enable the integrated authentication mechanism, it's necessary to define a couple of properties in the ekp.properties configuration file (under the WEB-INF/conf/ directory), as shown below.
The significance of these properties and their values is explained below. In addition, another optional property may be specified, as shown below.
The value of this property specifies the cryptographic hash function that will be used as part of the authentication process, as explained below. Permitted values are MD5 and SHA. If this property is not specified, a default value of MD5 is assumed.
EKP will also append a query string parameter named salt to the URL that is the target of the redirect. The value of this parameter is a random sequence of bytes, converted to characters using Base64 encoding. The purpose of the salt value is to prevent replay attacks—which is to say that if an attacker was able to intercept the URL generated by the portal as described below, they would not be able to reuse it authenticate against EKP after the salt value expired.
An example of a possible redirect target URL is shown below.
On receiving the request from the redirected client, the portal needs to perform the following steps.
Recover the original bytes of the salt by Base64-decoding the URL parameter value.
Authenticate the user if she does not already have a session with the portal.
Using the function configured as described previously, calculate a cryptographic hash of the user ID, secret key (this is the value of the authentication.key property described above) and salt value.
Convert the bytes of the cryptographic hash to a character string using Base64.
Redirect the client back to EKP's authenticationTokenVerifier transaction, passing both the user ID and the Base64-encoded cryptographic hash as query string parameters.
For example, assuming that the user is authenticated by the portal as joestudent, and the secret key is mysecretkey, then the MD5 cryptographic hash (after Base64 encoding) would be vf1nZ7R2YSoso+g+BLLVog==, and the EKP URL to which the portal would redirect the client would look as shown below.
On receiving the request from the redirected client, EKP will perform its own computation of the cryptographic hash and compare it with the value passed by the portal. If the values match, this is accepted as proof that the redirect was actually generated by the portal and was not "spoofed". EKP then considers the client to be authenticated and establishes a session with the client.
The following sample code provides an outline of how the mechanism described above might be implemented as a Java servlet.
// string, so we can pass it in the URL.
// escape any special characters.
The mechanism described in this post works in EKP 4.6 Gold build 116 or higher, and in EKP 4.7 Gold build 52 or higher.
Rully, yes, absolutely. You would just need to create a page (.aspx, .jsp, .php etc.) that uses your database table to authenticate the user instead of hard-coding the userId as in my example.
Dear Rob could you help me about my issue using PHP?
i have a portal named SitePortal and i need to do an integration if my user have an account through EKP then i need to allow him to access EKP site without authentication.
Anonymous, you should start with the PHP sample authentication service.
i have checked the url that you have been sent, i did the same steps but should i set the external authentication = YES ?
thanks again rob, but what is the needed code should be implemented to let me see that myuser is authenticated and can access Net Diminsion Account ?
Ravie, I'm not sure I understand what you are trying to accomplish?
Typically, authentication would happen within your portal, after which you would redirect the user to Talent Suite with the appropriate parameters. Assuming all is well, the user will then be signed into Talent Suite. After that, there would not normally be any redirects back to your portal.
So it's not clear to me at what point you would that check to occur, or why you think authentication might fail?
A site identifying as http://MyPortal.com/auth_callback.php attempted to discover your identity.
The attempt was blocked because the site is not permitted to access this information."
You need to configure MyPortal.com as a trusted relying party.
Could you please provided me about the needed steps to do that ?
"You need to configure MyPortal.com as a trusted relying party."
assume my portal is "192.168.10.15/MyPortal"