Date: Wed, 5 Aug 2020 05:32:21 +0000 (UTC) Message-ID: <721635522.5947.1596605541468@confluence-docs-openathens-net-vm.c.support-tools-202207.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5946_811557487.1596605541468" ------=_Part_5946_811557487.1596605541468 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html How to handle walk-in users

How to handle walk-in users

=20

"Walk-in user" is a common term for people who are allowed to use your l= ibrary but are not otherwise part of your organisation - e.g. a University = Library might have an arrangement with the local community that the general= public can access library resources if they come into the library building= s.

=20 =20

Access accounts

OpenAthens offers an account type known as an 'Access account' which is = great for walk-in users because that type can be shared amongst multiple us= ers and has an IP based restriction on it so that you can limit it to your = network or even (with the help of your IT team) to the specific computers u= sed by walk-in users. The IP restriction means that it is perfectly accepta= ble to do things such as post the credentials on a sign on the wall or simi= lar.

To create an access account, select it as the option in the Accounts >= ; Add menu (for details see: A= dd - Access account).

The access account will access resources like any other account except f= or the location restriction. It's only really necessary though if you are o= ffering resources that don't use IP as the authorisation method.

If you a= re using local authentication

If your site uses local accounts - i.e. you have connected OpenAthens to= your own directory for authentications - then access accounts are still li= kely to be the best solutions for walk-in users as each ID your systems pas= s to us must represent an individual... and it is often the case that sites= do not want to create those records for walk-in users anyway. The practica= lities of the access accounts in use are:

If you are already using OpenAthens accounts alongside = local accounts

Access account credentials are submitted in the same way as any other Op= enAthens account, so your existing procedures can still apply

If y= ou are using the LDAP or Sirsi connector

The username and password fields on the authentication point will accept= the access account credentials without the need for any changes. You can u= pdate the username and password labels if necessary. 

If you are using a SAML or API connector such as ADFS, A= zure, Google, CAS

There are two options:

  1. Enable the function that presents users with the option to sign in with= either type of account
    • This will display the option to all users at least once - the user's ch= oice is remembered so users should only see it once on their personal devic= es
    • If regular users and walk-in users access the same terminals, the choic= es of one group may impact the experience of the other group depending on h= ow your terminals handle cookies
    • You will have to remove the default flag from your connection
  2. Ensure the walk-in users sign into OpenAthens before they try to access= any content

Advanced options

As well as an API connector which will start an OpenAthens session based= on your authentication process, we also have an API based option to start = a session for an OpenAthens personal or access account. Depending on how wa= lk-in users access your terminals, your IT team may be able to use this fun= ctionality to both simplify and even hide the process from walk-in users. S= ee: Generating authentication tokens for end-users via the API=

Licensing

You will no doubt have checked that the licences you have for the conten= t you are providing covers use by walk-in users... but you also need to che= ck with the publisher that it covers access by the methods you will be usin= g. Some publishers may not be willing to provide federated access to potent= ially unidentifiable users. Should such a case come up you will have to fall back to IP = authentication for walk-in users for that content.

Restricting whi= ch resources an account can access

If your walk-in= users can only be allowed access to a subset of the resources that you sub= scribe to, you can restrict their access by using permission sets and restrictive mode. There are a couple of approaches:


Example for a single organisation
  1. If you do not already have any permission sets under the organisation you will need to create at= least two
    1. One set for the walk-in users with the restricted set of resource= s allocated to it. Set its role as 'library-walk-in'.
    2. One or more sets for the regular users with the relevant resource= s allocated to them. The role for these is usually 'member'
  2. Create the access account(s) for your walk-in users, assigning the permi= ssion set you created (Accounts > Add > Access account)=
  3. Allocate the other permission set(s) to the regular accounts if t= hey are not already using them 
    1. For OpenAthens accounts this is done via search or list results and the= actions button - see: Search actions
    2. For local connectors this is done via the permissions tab on your conne= ction - see: Permission s= et rules
  4. If not already activated, turn on restrictive mode
Example using a dedicated sub-organisat= ion
  1. Create a sub-organisation (Accounts > Add > Organisation). Do not= assign it a unique identifier or scope.
  2. Impersonate that sub-organis= ation
  3. Create a permission set con= taining the resources available to walk-in users and set the role as 'libra= ry-walk-in'.
  4. Create the access account(= s) for your walk-in users, assigning the permission set you created (Ac= counts > Add > Access account)
  5. Turn on restrictive mo= de (Preferences > Organisation)

The main factor in choosing an approach is how you want things to appear= in the reporting interface - the sub-org option will not include the walk-= in users in reports unless you change the scope of the report to be all org= anisations, whereas the single organisation option will include them all to= gether and include the walk-in users' in permission set reports. 

Anything else t= o watch out for

Some federations do not permit shared accounts and require that all user= s be uniquely identifiable (e.g. UK Access Management federation). Access a= ccounts will not work for organisation / resource combinations within those= federations where we know these restrictions exist.

=20 =20
=20

------=_Part_5946_811557487.1596605541468--
https://docs.openathens.net/exportword?pageId=328180
docs.openathens.net
crawl=CC-MAIN-2020-34
18053
application/http; msgtype=response
sha1:QLOM56FBGJDUV7QCPSMGL3NGVVDL67PO
<urn:uuid:d15368b4-ee54-40ad-8c11-0bda62e218ff>
2020-08-05T05:32:21Z
35.241.20.47
message/rfc822
sha1:F6Z2CTD6C3NIKACVDY2TFKELP4DGOPX2
<urn:uuid:05b618aa-5820-4a65-a964-f25ea37c4832>
https://docs.openathens.net/exportword?pageId=328180
response
<urn:uuid:93197e56-8072-4a50-9094-9aaa1962831b>
isPartOf: CC-MAIN-2020-34
publisher: Common Crawl
description: Wide crawl of the web for August 2020
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-62.ec2.internal
software: Apache Nutch 1.17 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/