From ca57eb37eb18afdf6c2abd64d60dbee32a4be695 Mon Sep 17 00:00:00 2001 From: Mike Taylor Date: Tue, 1 Jul 2014 18:29:24 +0100 Subject: [PATCH] Better description of setting SP auth URL. --- doc/library-configuration.txt | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/doc/library-configuration.txt b/doc/library-configuration.txt index 3b061aa..18c0cd4 100644 --- a/doc/library-configuration.txt +++ b/doc/library-configuration.txt @@ -43,11 +43,13 @@ in the mkws_config structure: 2. Changing the library ----------------------- -Some MKWS applications will want to define their own library providing -a different range of available targets. This is particularly important -in the case of applications that authenticate onto subscription -resources by means of credentials stored in MKAdmin, in that such -library accounts need to prohibit unauthorised access. +Some MKWS applications will be content to use the default library with +its selection of targets. Most, though, will want to define their own +library providing a different range of available targets. An important +case is that of applications that authenticate onto subscription +resources by means of credentials stored in MKAdmin: precautions must +be taken so that such library accounts do not allow unauthorised +access. Setting up such a library is a two-stage process. @@ -56,7 +58,7 @@ Stage A (on MKAdmin) Create the library: - Make a new library on http://mkc-admin.indexdata.com/console/ - Select relevant targets - - Add authentication credentials as necessary + - Add authentication credentials to the targets as necessary - Create an end-user account - Set its username and password @@ -65,8 +67,14 @@ Stage B (on the application's web-server): Authentication onto the library can be achieved by a single HTTP GET to the relevant Service Proxy, passing in the credentials and thereby initiating an HTTP session. This can most simply be done just by -setting service_proxy_auth to a URL such as - http://mkws.indexdata.com/service-proxy/?command=auth&action=login&username=MIKE&password=SWORDFISH +setting the service_proxy_auth configuration item to a URL such as + http://mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=MIKE&password=SWORDFISH +which is usually done with JavaScript like: + + However, doing so reveals the the credentials to public view -- to anyone who does View Source on the MKWS application. This may be @@ -76,14 +84,15 @@ circumstances, a more elaborate approach is necessary. The idea is to make a local URL that is used for authentication onto the Service Proxy, hiding the credentials, and to use local mechanisms to limit access to that local authentication URL. Here is one way to do it when -Apache2 is the application's web-server: +Apache2 is the application's web-server, which we will call +example.com: - Add a rewriting authentication alias to the configuration: RewriteEngine on - RewriteRule /spauth/ http://mkws.indexdata.com/service-proxy/?command=auth&action=login&username=U&password=PW [P] - - Extend the MKWS configuration to set service_proxy_auth: - http://application.com/spauth/ - - Protect access to /apauth/ (e.g. using a .htaccess file). + RewriteRule /spauth/ http://mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=U&password=PW [P] + - Set thwe MKWS configuration item "service_proxy_auth" to: + http://example.com/spauth/ + - Protect access to http://example.com/spauth/ (e.g. using a .htaccess file). Once such a library has been set up, and access to it established, target selection within the set that it makes available can be done -- 1.7.10.4