Can I launch courses directly from a portal so that learners don't have to log into EKP, but still have EKP track the learners' progress?

In order to link to a course so that the course launches immediately, and is tracked by EKP, you can link to the launchByCourseId transaction, e.g.:

/ekp/servlet/ekp/launchByCourseId?courseId=My_Course

(Note that this requires that the learner already be enrolled in My_Course, so you might want to pre-enroll learners using a Group Enroll or Auto-Enroll.)

If you link directly to the URL above, and the learner does not yet have a session with EKP, she will be prompted to log in as normal. In order to achieve “transparent login”, you can use one of the two mechanisms described below.

1. Implement the "external authentication service" mechanism. To implement this, the portal would need to be modified to generate “authentication tokens” (cryptographic hashes) when requested by EKP. Then, EKP's configuration is modified so that, when it needs to authenticate a user, it redirects to the portal to request an authentication token instead of showing the standard login page.
   
   Note that this mechanism has the significant advantage that it is not required that users' passwords be synchronized in the two systems. In fact, when using this mechanism, the passwords stored in EKP's database are never used.
2. Use the standard verify transaction. This is the transaction that is used to validate a user ID and password submitted using the normal login page. It is possible to add a target parameter to specify the page to which the user should be redirected after a successful login (instead of the normal home page). In particular, if you want to start a course after login, you can specify the launchByCourseId transaction (with appropriate courseId parameter value) as the value of the target parameter. E.g.:

   /ekp/servlet/ekp?TX=VERIFY&UID=joestudent&PWD=password&target=%2Fekp%2Fservlet%2Fekp%2FlaunchByCourseId%3FcourseId%3DMy_Course

   Note that the value of the target parameter has been percent-encoded.
   
   The above example includes the parameters in the query string—however, for security reasons you should avoid including the user ID and password in the URL—therefore, the portal should be coded to use the POST method rather than GET to invoke the verify transaction.

Note that, unlike method 1, method 2 requires passwords to be synchronized between the two systems, which could be difficult to achieve if passwords are changed regularly (a good security practice). (This problem can be avoided by configuring both systems to use the same directory server, i.e. Active Directory or LDAP.) In addition, method 2 requires embedding the user's password in an HTML page (or HTTP redirect header), which might be cached. For these reasons, we recommend using method 1 if possible.