Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    www-x account and security

    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    I am involved with a project that is looking at using the Aleph x-server circ_status function to get real time circulation information. But some people on the project feel that there is a security hole in that the www-x account allows access to the system without a password. Do you think this is a security problem? While I understand the concern, my understanding is that setting privileges appropriately on the www-x account is the way to limit server access, and this method provides strong security.

    [From Ex Libris:] I'm sure you already have seen the responses to your query to the X-Server list, particularly ones from Ken Mitchell at Duke and Jimmy Ghaphery at VCU [below]. I do not have much to add to these excellent suggestions.

    In these security-conscious times, it may seem odd to have services like this that are not password-secured, but I think the developers had a different security model in mind. The way that Mr. Ghaphery described of using the server_ip_allowed table to control the server from which these calls can be made seems to me to be the heart of the security envisioned by the developers. If X-Service calls can only come from one server (or a few), it is much easier to control who will have access to the data that is returned.

    So, while it is possible to make the X-Server extremely unprotected, in practice it would be unusual for it to be anything other than very secure, through the use of a few standard security measures.

    We may be able to help you set some of this up once you decide how you wish to proceed. However, the X-Services package is very much a do-it-yourself type of interface and you may be able to get as much practical help from the X-Service list as you will from us. Please let us know how we can help you. If this pretty much answers your questions, feel free to close the incident.

    Alan Manifold

    [From Jimmy Ghaphery:]

    In addition to these excellent suggestions, you can also add other
    layers that may help.

    For our use of x-services to display patron data on the portal we
    stripped down the xml to only give us the data we wanted, and thus are
    not exposing things like address, etc. We did that through the
    /alephe/www_x_eng/bor-info.tag with a lot of lines for "DELETE". This
    also made the xml lighter for what it's worth.

    Also we use /alephe/tab/server_ip_allowed to lock down what ip's can
    even access the x-server (in our case the portal server, metalib server,
    and a few individual developers).

    Jimmy Ghaphery
    Head, Library Information Systems
    VCU Libraries

    Ken Mitchell wrote:
    > Mike,
    > While I'm not sure that I would characterize it as a "strong security"
    > method, I would definitely recommend limiting the number of X-Server
    > functions available to the WWW-X user to a subset of functions that
    > don't involve any user account information (either account transactions
    > or loan information).
    > The primary reason that we do this is that several patron-based X-Server
    > functions (e.g. bor-info, bor-by-course, similar ill-based calls) do not
    > require the user's authentication credentials to provide patron
    > information (even in the documentation, the "verification" parameter is
    > listed as "optional"). This can potentially make your entire patron
    > base visible, depending on how widely you allow access to the X-Server.
    > This could pose an issue to your library's privacy policy.
    > We get around this by constraining the WWW-X user to only a few API
    > calls, and if our X-Server users need access to other API functions, we
    > create a new ALEPH user (with a secure password), assign the appropriate
    > functions to that user in the ALEPH GUI "staff privileges" function, and
    > then ask that the X-Server users make all their transactions over https,
    > and append their calls with the (undocumented) "user_name" and
    > "user_password" parameters. (We prefer to have to send these
    > credentials as little as possible, and have discovered that, once an API
    > call has been made with the "user_name" and "user_password" parameters,
    > you can identify the session number returned in the API result, and then
    > use that session number in subsequent API calls to continue making API
    > calls using the non-WWW-X user. This improves the security of the
    > credentials somewhat.)

    • Article last edited: 10/8/2013