JISC Final Report

vetinnocentSoftware and s/w Development

Nov 7, 2013 (3 years and 9 months ago)

165 views


JISC Final Report



Project Information

Project Identifier

To be completed by JISC

Project Title

Supporting Institutional Access to External Services

Project
Hashtag

#siaes

Start Date

1
st

February 2012

End Date

31
st

July 2012

Lead Institution

University of Bristol

Project Director

Simon Price

Project Manager

Debra Hiom

Contact email

d.hiom@bristol.ac.uk

Partner Institutions

Cardiff University, Durham University

Project Web URL

http://access.blogs.ilrt.org/

Programme Name

Directions: Access and identity management

Programme Manager

Christopher Brown


Document Information

Author(s)

Debra Hiom, Mike Gulliver, Ed Crewe

Project Role(s)

Project Manager, Project Researcher,
Technical Developer

Date

31/07/2012

Filename

Finalreport_siaes

URL

If this report is on your project web site

Access

This report is for general dissemination


Document History

Version

Date

Comments

0.1

17/6/2012

Draft for internal comments

1.0

1/10/2012

Draft for partner comments

Final

30/11/2012

Final version incorporating partner comments




Table of Contents


1

ACKNOWLEDGEMENTS

................................
................................
................................
............................

3

2

PROJECT SUMMARY

................................
................................
................................
................................
.

3

3

MAIN BODY OF REPORT

................................
................................
................................
...........................

3

3.1

P
ROJECT
O
UTPUTS AND
O
UTCOMES

................................
................................
................................
................

3

3.2

H
OW DID YOU GO ABOUT
ACHIEVING YOUR OUTPU
TS
/

OUTCOMES
?

................................
................................
......

4

3.2.1

Background

................................
................................
................................
................................
.....

4

3.2.2

Aims and Objectives

................................
................................
................................
........................

4

3.2.3

Methodology

................................
................................
................................
................................
...

4

3.2.4

Pilot organisations

................................
................................
................................
..........................

4

3.2.5

Technical implementation
................................
................................
................................
...............

5

3.3

W
HAT DID YOU LEARN
?

................................
................................
................................
................................

8

3.4

I
M
MEDIATE IMPACT

................................
................................
................................
................................
.....

8

3.5

F
UTURE IMPACT

................................
................................
................................
................................
..........

8

4

CONCLUSIONS

................................
................................
................................
................................
..........

9

5

IMPLICATIONS F
OR THE FUTURE

................................
................................
................................
............

10

6

APPENDICES

................................
................................
................................
................................
...........

11

USE

CASE

1

-

E
STABLISHMENT OF CONN
ECTION BETWEEN EXIST
ING
BOS

USER
_ID

AND
S
HIBBOLETH ATTRIBUTE
_ID
S RELEASED BY
INSTITUTION

................................
................................
................................
................................
.........................

11

USE

CASE

2

-

P
ROVISION ACCESS TO U
SERS FROM INSTITUTIO
NS ABLE TO ONLY RELE
ASE ATTRIBUTES THAT
IDENTIFY THE USER

..

13

USE

CASE

3

-

P
ROVISION USERS FROM
INSTITUTIONS ABLE TO

RELEASE ACCESS ATTRI
BUTES

................................
................

14

USE

CASE

4

-

C
REATION OF NEW USERS

................................
................................
................................
...................

16

USE

CASE

5

-

D
ELETION OF USERS

................................
................................
................................
...........................

17

USE

CASE

6

-

P
ERMISSION CHANGES FO
R USERS

................................
................................
................................
........

18

USE

CASE

7

-

M
ULTIPLE ACCOUNT LOGI
NS

................................
................................
................................
................

19

USE

CASE

8

-

N
EGOTIATING USER AND
DATA MOVES BETWEEN T
WO ACCOUNTS
................................
...............................

21


EXAMPLE DOCUMENTATIO
N...................
....................
....................
....................
....................
.......
...............
. 2
3


1

Acknowledgements

The project was funded under the Access and Identity Management Strand of the JISC
16/11 Programme. The project gratefully acknowledges the support of JISC and
the JISC
Programme Manager
Christopher Brown. We wou
ld especially like to thank Joan Wright and
Rhys Smith at Cardiff University and Malcolm Murray at Durham University for their
participation and input into the case studies and for the
contribution of the project steering
group at the University of Bristol, namely; Matthew Baker, Ralph Ballon, Gary
Brown, John
Hay, Kieren Pitts, Simon Price and Jasper Tredgold
.

2

Project Summary

The overall aim of
the
Supporting Institutional Access to External Services project was to
provide a case study
into the implementation issues around using Shibboleth for
group
management of a large scale national service
.

The project worked with two existing
institutional users of the BOS Service (Universities of Cardiff and Durham) to:



Identify policy issues which needed to be addressed on an institutional level to
provi
de flexible group management administration of accounts



Provide guidelines and example
documentation

on Shibboleth access to shared
services for non
-
technical staff

A number of existing required use cases were developed and refined during the project to
hi
ghlight some of the issues and potential IdM/account management problems, such as
auto
-
assigning groups using the Shibboleth entitlement attribute.

3

Main Body of Report

3.1

Project Outputs and Outcomes


Output /
Outcome Type

(e.g. report,
publication,
software,
knowledge built)

Brief Description and URLs (where applicable)

Case study
report

Case study report on the process of using Shibboleth for group
management available from

http://access.blogs.ilrt.org/files/2012/12/SIAES_casestudy_final.docx
:

Use case
scenarios

Available as part of the case study report above and also as Appendix 1
of this report.

Non technical
documentation

Available as part of the case study report

and Appendix 2 of this report.

Test I
dM
implementation

http://bos2
-
demo.ilrt.bris.ac.uk
/

Presentation
s

Creating Federated Authorisation for a Django Survey System
https://ep2012.europython.eu/conference/talks/creating
-
federated
-
authorisation
-
for
-
a
-
django
-
survey
-
system

Poster

https://docs.google.com/file/d/0B
6TNd6XgEH_LX2NEekNVV05ndzg/view

Knowledge built

Increased understanding of local IdM issues at pilot institutions to feed
process and procedures for the BOS service and to feed into wider
knowledge base of IdM community


3.2

How did you go about achieving
your outputs / outcomes?

3.2.1

Background

Bristol Online Surveys (BOS) is a web
-
based, survey creation and data
-
capture service,
provided to some 250 organisations
that

run either single, or multiple accounts. BOS is
accessed by a simple login, currently located

at http://www.survey.bris.ac.uk/


BOS accounts are discrete groupings of users and the surveys that they create. When a
user logs in, they are provided with access to permitted surveys, within a single account.
Access to

surveys within accounts
is control
led by a user

s ‘level’, and by permissions set on

individual surveys. The extent

to which access is fine
-
grained

depends on the functionality
running on the account. The project explored issues surrounding the application of
Shibboleth to BOS accounts

at

varying levels of permissions

to encompass the full range of
Shibboleth implementations at UK HEIs
.

3.2.2

Aims and Objectives

The overall aim of the project was to provide a case study and exemplar for large
-
scale
shared services to implement Shibboleth for

HE services. In particular the project
worked
with Cardiff and Durham Universities

as pilot institutions

to:




Identify policy issues which needed to be addressed on an institutional level to
provide flexible group management administration of accounts



Pr
ovide guidelines and example
documentation

on Shibboleth access to shared
services for non
-
technical staff

3.2.3

Methodology

BOS has a mixture of HE, governmental and commercial clien
ts. Although the majority

of the
HEI clients have their own IdM systems there i
s a wide variet
y of approaches to managing
identity management within their organisations
. The

project explored a number of
use cases
,
looking at

how Shibboleth could be implemented to support the BOS system requirements
within the capacity and working pra
ctices of the pilot institutions. The use cases covered

the
following scenarios
:




Facilitating
Shibboleth
access to BOS

for existing users

(both for the first time, and
on an ongoing basis)



Facilitating
Shibboleth
access to BOS
for new users



Deletion of u
sers



Permission changes for users



Supporting multiple account logins



Moving users and data between institutional accounts


Each use case was examined in terms
of technical and policy

options, these were then
sanity
-
checked by the pilot institutions (Cardiff and Durham) to make sure that they could be
sup
ported both by their current identity management system and their administrative

/procedural systems. The detailed use c
ases are ava
ilable as
Appendix 1
.


Sample implementation documentation has been produced to support the use cases, this
includes options for Shibbolising BOS accounts and a draft FAQ for administrative users.
The documentation is available as
Appendix 2
.

3.2.4

Pilot organi
sations

In terms of Shibboleth implementation the procedural differences (i.e. requirements) for an
institution matter in terms of how they are married up with the technical capabilities of that
organisation. The two examples from the pilot institutions a
re useful in that they mark either
end of the scale of identity management capabilities.

Durham University

Durham
has a single individual acting as
the
P
rimary
C
ontact (PC)
, who provides access to
BOS based on two selection systems:




All members of staff
are provide
d with automatic

access. In other words, any member of
Durham staff who requests access is automatically assumed to have a legitimate reason
for its use, and so is set up by the PC with a user account.




Other applicants are individually vetted
by the PC to ensure that they have a legitimate
reason for requesting access to BOS and an understanding of the data protection
responsibilities that they undertake in using the tool (
e.g.

they are a research student
who can demonstrate ethical management
of research data, or a non
-
member of the
university who is involved in research requiring BOS access).


This secondary, vetting process is not contingent on specific qualifications, but is judged by
the PC at the time of application. Once approved, the PC

creates the user account at the
appropriate level, communicating the username and password to the user.


Durham does not yet have a central identity management
system in place (although one is
planned for
the

near

future). Because of this they are only
capable of releasing minimal user
information via Shibboleth to the UK Federation. That is the attribute
(eduPersonScopedAffiliation) which
provides users with

a single ‘member’ status if they are
a member of the University (i.e. staff or student) and a p
ersistent opaque identifier for users.
This means that users cannot automatically be identified from their Shibboleth login or
checked to see if they are a member of staff.

Cardiff University

Cardiff
has a role
-
based team acting as PC, who set up users ba
sed
on
the applicant’s
completion of a data
-
management course. This system is run through an application form,
which allows the PC to capture a wide range of applicants, and to filter them towa
rds
satisfaction of the criterion
. All applicants who are membe
rs of staff, and who have
completed a data
-
management course, are automatically provided with access to BOS.

Users of other types (students, or affiliated personnel) may be provided with access to BOS.
If they
are
allowed access to BOS, this is ascertained

before the completion of the data
-
management course
-

and so the data
-
management course completion criterion can also be
used in this case to determine their eligibility for BOS access.


Cardiff has a full identity management system in place, with the fac
ility to release user data
and assign attributes to users related to the groups that they belong to within the University.
The group data is fine grained, for example information related to their membership o
f a sub
-
organisation or unit could potentially

b
e surfaced (along with their status as having
completed the BOS data
-
management course).

3.2.5

Technical i
mplementation


The main technical development involved creating the authorisation API for the
BOS
application so that decorator functions

(a type of macro functionality within Python
programming)

could be added to the code that test the permissions a user has both from
remote Shibboleth entitlements and local group membership. Web pages, surveys etc. can
then
use a

simple syntax such as @pe
rmissions(’lock’, ‘delete’) at the top of the classes to
protect them.


Before gaining access to the protected object the user is checked, if unauthorised they are
redirected to login and on login their Shibboleth entitlements and local group memberships
are checked for roles, which are then tested for permissions.

A system to allocate
permissions to roles for the various objects (e.g. survey, user, folder) in the application was
also created.


We adapted the Open Source federation system Authentic2
1

and

integrated it into the BOS
service provided for through the web configuration of SAML2

policies, attribute mapping and
IdP and SP setup, using upload or automated syncing of XML files. For use with Shibboleth
SAML2 there was a need to modify its default u
ser creation to use the appropriate
e
duPerson attributes for user
p
roperties. It also provided multiple login identity mapping
functionality for users, so that a single user could potentially have identities from more than
one institution or more than one
protocol, e.g. SAML2, CAS and OpenID.


Different institutions require different levels of Shibboleth access


at its simplest
-

n
one (
e.g.
non UK HE member)
, authentication

only, authentication and authorisation. Many also
require local
a
uthentication and
authorisation to continue due to
needing to support
external
users, and the issues detailed below.


For this reason there are different I
d
P configuration profiles that an I
d
P may be assigned to,
and so a service level federation configuration layer is requ
ired, rather than just directly
using the UK federation. This is also needed due to a future requirement for other SSO
solutions to be configured for commercial clients via the Authentic2 federation tool, e.g.
Google SAML, OpenID etc.


Hence work was under
taken to automate update of I
d
P metadata from the UK federation,
through to the BOS Authentic
2

Federation tool.





Figure A: screenshot showing aggregated IdP configuration

customisation via web console


An external
Service
P
rovider

(SP)

will be running an application that will have its own
bespoke authorisation related to the requirements and features of that application. For
the
BOS
service
we have chosen to apply a role based access con
trol layer (RBAC) to our
system

to act as an abstr
action layer from the fine details of permissions and object access,
e.g. account, folder, survey. The hope is that as RBAC is such a common authorisation
model it may provide more general lessons than pure be
spoke rules and raw permissions

based access c
ould do. So the survey system can be approached more like a generic
content management system. There are surveys and higher level groupings of surveys;
these have many permissions such as edit, lock, view etc. but the permissions can be
grouped into just a

handful of roles. The roles are then applied to a survey(s) for a group.
The group is populated by users, which gives them the permissions on the survey(s).





1

http://packages.python.org/authentic2/

For providing authorisation via Shibboleth the allocation of these roles for users on surveys
can

be done specifically by entitlement attributes. The entitlement attributes for a user are
checked as part of the authorisation machinery. If the entitlement is found the user gets the
pe
rmission, if not then the local authorisation based on groups is chec
ked. These two routes
to authorisation must remain in

parallel because many institutions have not yet got the
capability of setting detailed attributes for their users (e.g. Durham can only set one attribute
currently). If attributes cannot be set remotely

then they must be set locally


or at least the
roles that they would determine, must be set.


When we do have roles assigned from remote attributes we must not cache them,

we cannot
store permissio
ns allocated remotely, since we have no means of determin
ing the lifespan of
those permissions. Hence a user who was given permission to delete a survey should not
have that permission cached by the SP. Instead it should just exist for the duration of their
login session. Due to this restriction is not viable to

merge remote and local authorisations, a
user may have one role from remote entitlements and another from BOS group membership,
but they
should not
have a role that is dependent on a combination of these because it
would require caching of the remote enti
tlements
.


3.2.5.1

Setting access rights via entitlements

The BOS roles used are superuser, administrator, author, viewer and respondent. In order to
set a specific authorisation then the entitlement attributes need to explicitly set one of these
roles for a user
on one or more objects. So the standard for explicit entitlements that we
have
created is:


bos:account:role:object:(id or codename):(ex/include:list)


N.B

brackets indicate optional arguments


A

user with explicit entitlements set will have a comma separated list of one or more of these
entitlements set by their IdP to give specific authorisations in BOS.


Analysing the colon separated elements in more detail we have:

1.

bos:

a prefix to identify t
he entitlement as being related to the BOS SP

2.

account:

the identifier for the Shibboleth issuer URL
-

since users may have
entitlement from more than one institution

3.

role:

the set of permissions being allocated, eg. author

4.

object: the account, folder or
survey to which the user is being given the role

5.

(id or codename):
a specific identifier for the object
-

if absent all objects of the
specified type are being given access
-

eg. setting author rights on all surveys

6.

(include or exclude):

a means to be semi
-
explicit with attribute setting. So an IdP
may have a group management tool that can set author for all members of a
department on a particular folder of surveys, but then want to exclude access for
students or honorary staff. By adding
exclude=eduPersonA
ffiliation:students,honorary at the end this can be managed by
just triggering writing the entitlement once, as long as they are also releasing
eduPersonScopedAffiliation

Examples

To give a user administrator rights in the Durham account, this would be spe
cified as:


bos:durham.ac.uk:admin:account


To give a user at Cardiff the rights to author and

delete surveys in the medical folder, the
entitlement attributes would be specified as:


bos:cardiff.ac.uk:author:folder:medical



To give a user at Cardiff th
e right to respond to surveys in the personnel folder as long as
they are not a student would be specified as:


bos:cardiff.ac.uk:respondent:folder:personnel:exclude=eduPersonAffiliation:student@cardiff.
ac.uk

Mapping attributes


If on the other hand BOS
wants to make more use of existing attributes set based on
provisioned groups then we may have users that have the following set, i.e. only one BOS
specific simple entitlement, indicating they have attended the institution’s training to use
BOS ...


eduPer
sonEntitlement = bos
-
accredited

eduPersonE
n
titlement

= medical
-
faculty@cardiff.ac.uk


Within BOS we
will
need to implement a mapping tool that allows administrators to apply a
set of entitlement rules to give matching users the medical author role for the
duration of
their login session. So for the medical folder they can enter a role entitlement mapping of


bos:cardiff.ac.uk:author:folder:medical



can be set via a BOS authorisation mapping from the Shibboleth attributes:


i
nclude=eduPersonEntitlement
:
medical
-
faculty@cardiff.ac.uk
, eduPersonEntitlement:bos
-
accredited,exclude=eduPersonAffiliation:student@cardiff.ac.uk


So for the institution the options are either to do everything within their local syst
ems, but
require service provider specific authorisation entitlements to be set by their local IdM
systems, or to use more general entitlements locally
-

but with the need to also add
configuration data that map the generic entitlements to SP specific ones
, within their SP
account.

3.3

What did you learn?

Discussions with
the pilot institutions

highlighte
d the need to provision
standard
Shibboleth
set ups for client organisations at both ends
of an Identity management scale
, catering for
organisations that have

tools in place to make entitlement attributes available from central

IdM

systems on demand, and also for organisations that have little or
no identity/
group
management system
s

in place. From discussion with
the pilot institutions
, it has also
become clear

that the lack of local structures to provision (for example) entitlem
ent attributes
will prevent BOS

from delivering all of the use
-
cases immediately upon release to all
partners. However, it will be possible to outline how those use
-
cases might be achiev
ed
given additional set up over time.

3.4

Immediate
i
mpact

Shibboleth access will not be offered to HE institutions until the servic
e moves to its new
platform in S
pring
/Summer of

2013. However it has been invaluable to
work through the
issues and
constraints

and to
get feedback from staff at the pilot institutions in Cardiff and
Durham

in order to be able to
offer

a flexible range of options for organisations

to use
Shibboleth.

3.5

Future
i
mpact

The outputs of the project will be used with the release of the

new version of BOS s
ervice
in

2013. At this point all BOS HE institutional clients
could

be offered the possibility of moving
over to Shibboleth as part of their migration to the new system. We plan to continue to
develop and refine documentation over th
e coming year in consultation with

HE

institutional
clients.


It is
also
hoped that the outcomes of this project will act as a guide to the process by which
similar services (either current or future projects)
can
adopt federated access

for group
managemen
t
.

4

Conclusions

BOS has a mixture of HE, governmental and commercial clients. Although the majority of
clients have their own IdM systems, the service also has to cater for individual accounts or
accounts for SME scale clients, whose only IdM may be the us
e of third party solutions from
public web service providers (e.g. Google and Facebook) such as OpenID. Future use cases
also need to cater for embedding and integration of survey services with other web based
applications, hence application to application

authorisation tools such as OAuth may also
have a place.

Given this evolution and requirements, the provision of remote authorisation
and authentication services cannot be fully replaced by Shibboleth use

for the BOS service
.



Our initial investigation
leads us to believe that IdPs are unlikely to be willing to set domain
specific entitlements (or to do any specific SP configuration)

because of the high IdP
administrative overheads of managing groups
. Coupled with t
he different capability levels of
Shibb
oleth for each IdP further complicates
the issue. So there will be

a need to assess on a
client by client basis, to what level an IdP would like to migrate to use of Shibboleth for
authorisation. Hence a number of policies for federated authorisation need
to be
implemented for different IdPs, and unfortunately a one size fits all approach is not viable.


This combination of factors leads to the need for a full federation management system for
the service provider, to implement different attribute handling
policies, along with integrating
other open IdM protocols in addition to SAML2 via Shibboleth.


The BOS

system
that
was developed
was
based on an existing solution used by the French
public sector

(Authentic2)
, which allows local configuration per client,
but with tools to update
the metadata for the IdPs daily from the UK federation, so hopefully minimi
s
ing the extra
overhead that
full
federation man
agement entails. Currently the BOS f
ederation is just
configured with a demonstration service, until
the new

version of
BOS goes live

in 2013
.


In summary t
here are a

number of

technical
issues

arising from

the
project:


1.

The problems

of mapping domain specific authorisation to remote IdP
entitlement
based authorisation,
i.e.

Remote IdPs will normally not set attributes that are specific
to the SP. The domain authorisation is too complex and variant between IdP users,
to use IdP entitlements directly. Hence the need for a mapping tool

which means that
the IdP will only have to

release identity information which can then be mapped to
BOS accordingly
.

2.

The level of capabilities of IdPs varies widely hence some can only use Shibboleth
for authentication, whilst others can potentially manage all authorisation remotely.

Hence the ne
ed for different IdP profiles and SP federation
management of the
SP
level authorisation assignment
.

3.

Because of the
above
spectrum of IdP Shibboleth provision (ranging from
authentication only Shibboleth clients such as Durham to fully provisioned clients
such as Cardiff) t
here is a need to continue full authorisation management locally in
tandem with remote management
.
Essentially managing the authorisation in two
places is a usability
nightmare

for administrators.

Ideally to make this more viable the
syst
em needs to be able to query remote IdP users to check if they still exist and
what
their attributes

are
, so that remote authorisation can be read in combination with
setting local authorisation.
On initial inspection we believed that this may
have
be
en

po
ssible using the Native Shibboleth utility,
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPresolvertest

however
further investigation revealed

that
the
code is

for extracting attributes from XML
responses that have already been obtained for a specific user via SSO.


There are other software implementations of SAML2 that do allow this sort of
querying by trusted Service Providers, for example PingIdentity,

see
:

http://documentation.pingidentity.com/display/PF610/Attribute+Query+and+XASP

A similar tool might be worth considering for the UK Federation.


With regards t
o

the administrative aspects of the project

one of the main issues is that staff
controlling the administrative process are not the same as the technical staff looking after
the
identity management system

which may cause difficulties in communicating possi
bilities and
r
equirements. Generally there also seem to be

a lack of policy connections between
an
institution’s
technical and administrative systems
,

so if a user’s permissions (and hence
entitlements) change
on an HR system there
isn’t

an automatic workf
low to propagate this
usefully to an external service

provider

through to the identity management tool.

5

Recommendations/
Implications for the future


There is no common standard or generic language for domain level security allocation
across different applications. If such a standard existed it would make a tool to map
between it and the type of user categorisation entitlement attributes more viable be
tween
different applications. However it is likely that every domain specific application is likely to
have their own standard so there will be a continued need to have a translation between the
remote IdP and the application.


Similarly it may be worth wi
der
consideration

of a tool to query remote IdP users for the
reasons outlined in the previous section
. However there are clearly significant security and
data protection issues that would be associated with providing such open directory querying
capabilit
ies in Shibboleth.


A specific recommendation for BOS in the future would be for the service to develop a
collection of standard set
-
ups for implementing Shibboleth access to BOS which institutions
could sign
-
up to.



6

Appendices


Appendix
1


Use

Cases


USE CASE 1
-

Establishment of connection between existing BOS user_ID and
Shibboleth attribute_IDs released by institution

Background

BOS must ensure that institutions are able to make choices about how extensively to implement
Shibbolised access, and are
empowered to manage both Shibbolised and non
-
Shibbolised access of
users based on local governance.


To allow BOS to provide access through Shibbolised authentication, BOS must first establish a link
between the attributes that an institution provides, and

its own, native user_IDs.

The following are defined as core attributes for the UK Federation:




eduPersonScopedAffiliation


relationship of user with institution
e.g.

staff@durham.ac.uk



eduPersonTargetedID


a persistent user pseudonym e.g.
JBxMwF5rsKXG8CQCQ9VCJsvvww0=@cf.ac.uk



eduPersonPrincipalName
-

persistent identifier often the individuals SSO id e.g.
jwxet2998@bris.ac.uk



eduPersonEntitlement


additional specific conditions need to access a particular resource
e.g.

urn:mace:dir:entitlem
ent:common
-
lib
-
terms is commonly used to denote anyone entitled
to access a general university library electronic resource

The minimum release of information that the UK Federation requires an IdP to release about its
members is the eduPersonScopedAffiliat
ion attribute. However BOS also requires the
eduPersonTargetedID in order to be able to link the two accounts together.

Technical challenges:



Create the link between

a Shibboleth

attribute_ID released by an institution, and a BOS
user_ID
:

o

Institution pro
vides sufficient information attributes to allow BOS to automatically
identify the user
e.g.

email

o

If above not available the user must log in locally in addition to Shibboleth and link
their BOS user_id to their Shibboleth login.



Remove native BOS

user
_I
D access once the Shibbolised access has been established.



Provide a way for native BOS

user
_IDs to be reactivated should the need arise.

Policy issues:

Institutional permission to use BOS should be understood as already given, signalled by the presence
of an existing BOS user_ID.

Institutions are required to select how extensively to require Shibbolisation of access. Choices to
include:



Mandatory Shibboli
sation of all users
-

so no native BOS logins would remain active on the
account.



Mandatory Shibbolisation of all institutionally recognised users
-

so native BOS logins would
remain active, but only for non
-
member users.



User choice to Shibbolise

access t
o their account
.


Existing BOS user
arrives at BOS site
User redirected to
authenticate at
registered
institution
User
successfully
authenticates
BOS maps attributes
governing access to
areas of the BOS account
END
Yes
No
Institution releases
recognised Shib
ID and attributes
governing access
BOS provides access to
specific areas of the BOS
account
Attribute map


Figure 1: Connecting BOS accounts through Shibboleth attributes

USE CASE 2
-

Provision access to users from institutions able to only release
attributes that identify the user

Background

To allow users to access BOS accounts, BOS must be able to provide access to those accounts
when presented with a valid Shibboleth attribute_ID.

Ideally, Shibboleth would provide an automated
way to allow users access to only relevant areas of a BOS accou
nt. However, some institutions are
able only to release attributes that identify a user rather than any specific entitlements such as group
or organisational unit.

BOS must, therefore, be able to recognise these attributes in isolation, interpret
them as l
inked to a stored BOS user_ID, and facilitate access to that BOS user_ID’s BOS account.

In addition, BOS must allow restrictions on access to be added within BOS itself, and in ways that
over
-
ride the ‘all areas’ access.

Technical challenges:



Identify use
r’s persistent ID as linked to a BOS user_ID



Provide access to BOS account



Provide means to enforce restrictions at survey level to users within BOS, ensuring that these
override permissions granted by Shibbolised access.

Policy issues:

Since Shibboleth o
nly controls gatekeeper access to the service, any additional permission remains
under the manual administration of the account PC.


Therefore, any change of status of a member of the institution that would result in a change of access
to BOS (for example
, a member of staff leaves to become a student having previously enjoyed access
to a staff
-
only BOS account), that is not represented by a change in their ability to authenticate, needs
to be communicated to the account PC so that manual checks are in plac
e.


Existing BOS user
arrives at BOS site
User redirected to
authenticate at
registered
institution
User
successfully
authenticates
BOS provides access
based on native access
settings
.
END
Yes
No
Institution releases
recognised ID

Figure 2: Provision of access using only user identification information from Shibboleth

USE CASE 3
-

Provision users from institutions able to release
access
attributes

Background

One of the key advantages of
Shibbolising access to BOS is that it allows control of data and surveys
within the BOS account to be defined ‘up stream’, by the institution, without the direct intervention of
the account PC.

However, to allow this to happen, information about the areas
of the BOS account
that a particular user should be able to access need to be communicated to BOS in a form that it can
interpret and implement.


Our syntax
for providing explicit entitlements is as follows:


bos:account:role:object:(id or codename):(ex/in
clude:list)


N.B

brackets indicate optional arguments

Examples

To specify that a user has administrator rights in the Durham account would be specified as:

bos:durham.ac.uk:admin:account


To give a user at Cardiff the rights to author and

delete surveys
in the medical folder, the entitlement
attributes would be specified as:


bos:cardiff.ac.uk:author:folder:medical



To give a user at Cardiff the right to respond to surveys in the personnel folder as long as they are not
a student would be specified as:


bos:cardiff.ac.uk:respondent:folder:personnel:exclude=eduPersonAffiliation:student@cardiff.ac.uk

Technical challenges:



Interpret attributes released to ensure that nuanced access is provided to a BOS account



Ensure that native BOS security settings can al
so be applied to override Shibbolised,
inherited permissions.

Policy issues:

Since access to areas of the BOS account is administered automatically by release of attributes,
institutions need to
align
their BOS data management policies into the provision o
f those attributes.
How they do this is
left
to the

institution to decide and implement
.


Existing BOS user
arrives at BOS site
User redirected to
authenticate at
registered
institution
User
successfully
authenticates
BOS maps attributes
governing access to
areas of the BOS account
END
Yes
No
Institution releases
recognised ID and
attributes
governing access
BOS provides access to
specific areas of the BOS
account
Attribute map

Figure 3: Provision users from organisations able to release access attributes
USE CASE 4
-

Creation of new users


Background

This use
case looks at how institutions can adopt Shibboleth mediated control over creating new BOS
account user_IDs.

Technical challenges:



Allow user to establish new BOS user_ID



Mediate between accounts where attributes are available to
automatically
approve user
s, and
those where attributes are not available



Where attributes are not available, refer creation to account PC


Figure 4: Creation of new users
USE CASE 5
-

Deletion of users


Background

Presently, BOS offers no automated way to d
elete users

from accounts
. Since Shibbolising a BOS
account potentially opens it to far greater numbers of users, and
provides account administrators with
the opportunity to relinquish direct scrutiny of those signing up to their account by
gatekeep
ing the

account based on a set of criteria,
there is a risk that

-

without the means for systematic
‘housekeeping’
-

the
account
may
accrue large numbers of obsolete users.


This use case
doesn’t really call on Shibboleth other than the fact that a users access t
o BOS will be
automatically removed when they leave the institution.


It also allows for a manual override, permitting
a
user to be restored to ‘native BOS access’, should
then continue to need access to the account, even if they are no longer able to auth
enticate through
an institution’s systems.

Technical challenges:



Adoption of
default
life
-
cycle
for BOS accounts



Ability
for institutions to configure their own life
-
cycle for their accounts



Ability to revert BOS logins back to native route.


Policy issues
:



Institutions will need to consider whether they would prefer to allow user

accounts
and
related
data to

go through a BOS mediated

decay

cycle
, or to
choose their own period for an account
life
-
cycle
.



Institutions will need policies to vet requests for the reinstatement of native BOS logins.




Figure 5: Deletion of Users
USE CASE 6
-

Permission changes for users

Background:

Currently, all permissions changes for users within BOS are administered manually. While this may be
appropriate for low
-
level actions, where individual users
can
set access on individual surveys, more
global applications can only be made manually by accou
nt administrators

(PCs)
.

Consequently, any changes that would require a wholesale shift in permissions pose a considerable
problem, and require a large investment of time and work.

One of the key advantages of a Shibbolised route into BOS is that, for inst
itutions able to furnish BOS
with attributes that can carry information about the areas of access that a user should have within a
BOS account, this information is passed to BOS at the point of login, and so is refreshed each time.

Technical challenges:

In

essence, there is no additional technical challenge here, other than the requirement to apply
permissions from mapped attributes to a user upon login, and the requirement to allow permission to
be defined within BOS itself to supplement those applied at l
ogin.

Policy issues:

Because permissions changes are automatically applied as the user logs in, institutions need to be
clear about how these will be defined, and who might apply them.


Institutions also need to consider how they wish to potentially separa
te general permissions applied
as the user logs in, and more specific permissions defined by users within BOS (with the latter,
overwriting the former where applicable).




Figure 7: Permission changes for users
Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 17/6/2012


Page
19

of
33

Document title:
JISC Final Report Template

Last updated: Feb 2011
-

v11.0


USE CASE 7
-

Multiple

account logins

Background

Current BOS users log in

to their account

with a native BOS login. Each account
effectively
bei
ng

a
separate ‘bin’ of surveys with
access to
their own data.

However, some users have legitimate access
to more than one account, and

sometimes need to be able to refer to surveys and data in more than
one account in a single session.

T
his could be achieved by allowing users to ‘share’ surveys more
effectively between accounts. However, this places the control at the level of the survey
, and is
administered within BOS itself, removing the wider system
-
level control that Shibboleth can provide.

This
use case
, therefore, provides users with a way to access more than one account from any
legitimate BOS login, by providing login
-
controlled ‘
tunnels’ into those secondary accounts.

Technical challenges:

The key challenge here, was to provide a way to open multiple sessions within the same BOS login
session
-

and to ensure that any accounts that make access Shibboleth controlled, continue to en
joy
that control each time they are accessed.

Policy challenges:

In essence, there are no additional policy challenges
-

since each account is administered separately,
and access to each is controlled by either a BOS native, or Shibbolised login, the situ
ation is
essentially one in which a person has access to multiple, independent accounts.

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
20

of
33


User logs into BOS
account
1
BOS account
1
data available
User logs into BOS
account
2
BOS account
2
data available
Browser session
1
Browser session
2
Data available from BOS
account
2
through manual
export or share
Data available from BOS
account
1
through manual
export or share

Figure 8: Current BOS position

with multiple accounts





Figure 9: Shibbolised BOS

and multiple accounts
Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
21

of
33

USE CASE 8
-

Negotiating user

and data moves between two
accounts

Background

In
the
current BOS

set
-
up
, user access is manually controlled. Therefore, if a user moves from
institution X to institution Y, unless
the institution X

account administrator intervenes

to close the
account
, t
heir access to institution X’s BOS account continues.

Because of this, the tendency has been for users legitimately moving from account X to account Y
who might need to take surveys and data with them, to simply leave their surveys in account X and
contin
ue to access them there.


This clearly has implications both for the management of the user’s data, which remains within an
inappropriate account, and for the user’s ongoing access to that account which is unregulated by
policies within the institution.


This use case explored how Shibbolising access to an account might prevent access when a user
leaves, return control of the data (and of data moves) to the PC of the account where the data is
located, and provide a legitimate way for moving users to eithe
r take their data and surveys with them,
or continue to access it within the original account if appropriate.

This use case covers movement from a Shibbolised account X to both a Shibbolised, or unshibbolised
account Y.

Technical challenges:

The technical

challenges within this use case are:


1.

Remove access for a user leaving account X (provisioned by use case 5)

2.

Reinstate access for a user requiring native BOS access to account X (provisioned by use
case 5)

3.

Creation of a new user within account Y (provisio
ned by use case 4)

4.

Performance of a ‘move’ action for surveys marked to move from account X to account Y.

Policy challenges:

BOS provides functionality allowing users to move themselves between accounts X and Y, either
giving up access to X, or preserving
BOS
n
ative access to X, or preserving Shibbolised access to X.
This means that account PCs may meet move requests in a number of forms.


Only PCs will be able to action ‘move’ requests between accounts.


They should, therefore, ensure that they are famili
ar enough with BOS functionality and with the
different paths that a user may take in a move, to ensure that both users and surveys remain under
their control where appropriate. (See FAQs for more details).

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
22

of
33

User’s ability to
authenticate through
Shibboleth to BOS’s
account X is revoked
Survey move
User arrives at
organisation Y
Account X
Account Y
User sets up access to
account Y
User leaves
organisation X
Users surveys flagged
to PC as belonging to a
‘gone away’ user
.
User requests
move of surveys
from X PC
Move process
PC agrees to move
surveys
Surveys to remain in
X
,
but user to have
access
User’s Native
access to X
reinstated
END
Yes
No
Yes
No

Figure 10: Moving
surveys between institutions

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
23

of
33


Appendix 2


Sample Documentation


So you want to Shibbolise your institutional BOS account?

What is Shibboleth?

Shibboleth is a way of allowing institutions to provide access to web
-
based resources such as BOS
through a sing
le login.

How does it work?

Users arrive at BOS
-

but are directed to their own institutional login to authenticate. Based on a
successful log in there, they are returned to BOS
-

and given the appropriate level of access to the
service.

Why is Shibboleth
useful?

There are two main reasons to use Shibboleth to access BOS.


The first is that, depending on your institution’s rules about access to BOS, Shibboleth can allow
anyone who has a log on for your Single Sign On (SSO), to use BOS through that, rather
than by
logging in through BOS itself. This makes it easier for them to access BOS because they don’t have
to remember another set of usernames and passwords. It also makes it easier for you, because you
can rely on your SSO to control access to BOS, so yo
u don’t have to do it in BOS itself.


The second is that, by accessing information on who can and can’t use BOS, and what each person is
allowed to do within BOS, Shibboleth can automate things like user creation and deletion, and set up
access to differe
nt areas of your BOS account automatically. This saves you time, and makes your
control of users and data, more consistent and reliable.

I get all of that from Shibboleth?

You may get all of that from Shibboleth.

There are two ways of implementing Shibbol
eth
-

what you can do, depends on what you can set up
and provide as an institution.

The more basic implementation of Shibboleth allows you to use your own institutional authentication
as a way to access the BOS service. You’ll still need to be involved in

setting up users, and giving
them permissions within the service, but you won’t need to worry about deleting them if they leave
-

and they’ll be able to use their normal logins to access BOS, so you won’t have to worry about a
separate set of passwords et
c.

The more complex implementation of Shibboleth allows you to do everything above, but also allows
you to set up rules to control who can be created as a BOS user, and what areas of a BOS account
each person should access. You can make this as fine
-
graine
d as you like, dependent on what
information your institution can release.

That sounds like a lot of work

It takes a short amount of time to get Shibboleth set up properly to work with BOS
-

and you’ll need
the help of your IT team. But once it’s done, you
’ll find that it should save you lots of time in the end.

What would I need to do?

The first thing to do is talk to your IT people. You won’t be able to use Shibboleth without their help,
and you’ll need some information from them to know what level of Sh
ibboleth you can run.

You’ll need to ask them three basic questions:


1.

Are we set up to work with Shibbolised services?

If the answer to this is ‘yes’ then you can go ahead with question 2. If it’s ‘no’ then unfortunately you
won’t be able to use Shibboleth
.

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
24

of
33


2.

Can we release a persistent ID, such as eduPersonTargetedID?

Again, if the answer to this is ‘yes’, then you can use the simpler version of Shibbolised BOS on your
account. If the answer is ‘no’, then you can’t use Shibboleth.


3.

Can we release the more c
omplex Entitlement Attributes?

If the answer to this is also ‘yes’, then you can probably use the more advanced version of
Shibbolised BOS. If the answer is ‘no’, then you’ll be limited to more simple Shibboleth
implementation.

What do I need from my IT
people?

Your IT team will have to set up your institution’s Shibboleth relationship with BOS. They will need to
get in contact with us to do that.

Before they do that, they will need to know from you, what implementation of Shibboleth you want to
use.

How
do I decide?

If your IT team are able to release entitlement attributes, then both the more simple, and the more
advanced implementations of Shibboleth are available.


These questions will help you decide the pros and cons of each for you and your institu
tion.

If you can answer mostly ‘yes’, then it is likely that you’ll be able to run the more advanced
implementation of Shibboleth without too much difficulty. (You may need input from your IT team to
answer these)


If you answer mostly ‘no’, then these are

areas that you will need to address to run the more
advanced implementation of Shibboleth. You can always set up the simpler option in the meantime.


1.

Does your institution have a clear policy about who can use BOS?

2.

Are those allowed to use BOS definable i
n terms of clear categories? For example: ‘All staff’,
‘All students’, ‘All those who have completed a BOS training course?’

3.

Are those categories defined in some way in your institution’s internal databases and
systems?

4.

Does your institution run an Ident
ity Management System to define groups internally?

5.

Can your institutional systems release entitlement attributes based on member’s membership
of either internal database categories, or Identity Management System groups?

OK
-

I want to go ahead. What do I d
o now?

If you want to go ahead with Shibboleth, then you’ll need to contact us.

We will ask you to complete the following table, and will then be able to discuss how best to proceed.


Full name of your institution



Level of Shibboleth requested

Basic/advanced


For Basic Shibboleth

Please confirm that you will be
able to release a persistent ID
each time that a user
authenticates to access BOS

Yes/No

Persistent ID?

(for example,
eduPersonTargetedID)

For Advanced Shibboleth

Please confirm that yo
u have
read, and completed our
guidance on ‘mapping’ your
v敳⽎/

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
25

of
33

entitlement attribute release to
areas of BOS access.


Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
26

of
33

Mapping your Entitlement Attribute Release to areas of BOS access

Introduction

In order for BOS to give your users access to specific

areas within your institutional account your
organisation will need to release entitlement attributes to define the access that a specific user should
have to that account.

To make the provision of entitlement attributes as easy as possible, BOS can provi
de a ‘mapping’ tool
that allows you to define what each entitlement attribute means.

Entitlement can be granted to different areas at an account level, a folder level, or a survey level.

Entitlement can also be granted based on the permissions that the use
r has at each level.



Administrators
-

can access this area without restriction, and can administer other users



Editor/creators
-

can create and access their own surveys within this area



Respondents
-

can respond to surveys within this area

BOS understands

9 possible permutations of these areas, and gives each one a ‘string’.

As follows:


BOS Account

BOS folder

BOS survey

Administrator

…:account:admin

…:folder.admin

…:survey:admin

Editor/creator

…:account:edit

…:folder:edit

…:survey:edit

Respondent

…:account:respond

…:folder:respond

…:survey:respond


q漠ollow yo畲⁩湳瑩瑵瑩o湡l⁓桩b扯l整e⁳e琠tp⁴ 睯wk⁷it栠h桥se⁰ rm畴u瑩o湳Ⱐyo甠睩ll敥搠瑯tt敬l⁵
睨慴 yo畲u条湩s慴io渠n慮 r敬敡s攠e潲⁡ny 潦⁴ 敳攠e桡琠yo甠wa湴nt漠os攮


q漠ollow yo甠u漠oo
瑨t琬twe 灲潶i摥 愠a慰灩n朠go潬I⁴ a琠t敦i湥s⁴桥 levels ⁡ c敳sⰠI湤⁡ ks yo甠u潲o
yo畲u敮ti瑬敭敮琠t瑴物t畴u⁦orm.

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
27

of
33

BOS FAQs


Facilitating access of existing BOS users
through Shibboleth

A
ccessing BOS for the first time


How does a user become ‘recognis
ed’ by BOS?


A user

becomes recognised by BOS through a process that links their university institutional log in
with a BOS user account.


What happens is that you log in with your institution through your normal Single Sign On (SSO), and
then you log into

BOS using your normal BOS login. BOS links the two IDs and allows you to use your
SSO to log into BOS.


Note: BOS will then freeze your previous BOS login, so you will only be able to access the service
through your institution’s Single Sign On.


Does
this need to be done each time I log in?


No
-

unless you change your institutional ID, BOS will remember who you are, and recognise you
each time you log in.


What happens if I
do
change my institutional ID?


If you change your institutional ID, then BOS

won’t know who you are.

If this happens, and you still
want to access BOS, then you’ll need to tell your account administrator who will ‘unlock’ your original
BOS account, and go through the linking steps again.


I’ve
logged in, but I don’t have a BOS acc
ount to link to
-

what do I do?


If you’ve never used BOS before, you’ll need to set up a new user account. Follow the instructions for
‘new users’.


I’ve forgotten my BOS account details so I can log in with my SSO, but I can’t connect up my
BOS account.


Fol
low the instructions in BOS to get your credentials sent to you again. When you can successfully
log into BOS, then start the linking process again.


What if I can’t authenticate through Single Sign On?


If you have a legitimate need to use a BOS accou
nt, but can’t log in through Single Sign On, then you
should continue to access BOS using your normal BOS login.

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
28

of
33

Facilitating access of a recognised user to BOS


I’ve linked my university login to BOS, what does that mean?


It means that, now, each time
you log into BOS, you’ll be asked to access it through your university
institutional login.


This is a way of making it easier to connect to BOS, and making sure that you have the right levels of
access to the system.


What information is passed to BOS b
y my
institution
?


This depends on how your institution has set up access to the service.


Some institutions pass through lots of information, allowing them to centrally control what you can do
within the BOS account.


Some pass through only just enough
information to identify you to BOS each time you log in.

BOS only uses that information to provide access to your BOS account and doesn’t store it, or use it
for anything else.


Is there any way to know what information is being passed through?


If you’re

concerned about what information is being passed to BOS, you should contact your account
PC.


Can I still control what people do with my surveys and data?


Yes
-

BOS allows you to control what people do with your surveys
-

this won’t change with the
introduction of Shibboleth and will override anything that Shibboleth does.

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
29

of
33


Creation of new users in BOS


For users


I’ve never used BOS before, what do I do.


1.

Go to http://survey.bris.ac.uk

2.

Complete the login through your own institution

3.

Select ‘I don’t

yet have a BOS account’
-

and complete the information that BOS requests.

BOS may provide you with immediate access, or you may have to wait until your application for a
BOS account has been checked by your institution.


I’ve reached point 2, and received

a message that I’m not allowed to use BOS.


Nothing has gone wrong
-

the most likely reason for this is that your institution’s policies on the usage
of BOS means that you’re not allowed to use that account.


If you have any questions about this, you sho
uld contact the account administrator. They may have
made their details public at (URL).


If I can’t contact them, and I’m not allowed to use their account, what do I do?


If you’re not able to get access to an existing BOS account, then you’ll need to set

up a new account
to use BOS.




I’ve followed the instructions for ‘new users’
-

but BOS tells me that I can’t use my account
yet. Why?


The most likely reason for this is that your institution manually checks all new account requests before
they are avai
lable for use.

You should be hearing from your BOS account administrator soon with more information.


Why is BOS asking for information about me? Can’t it get it from my university?


To keep your details safe, your university doesn’t release personal info
rmation to BOS, so
-

to allow
you to use BOS
-

we need to ask you for some information.


For P
rimary
C
ontact
s


My account doesn’t set up users automatically, what’s my involvement?


If your account isn’t set up to create users automatically then you’ll n
eed to sign off each user as they
are created. BOS will collect information about them for you, and send it to you. All you’ll need to do is
vet their application and approve it, or not.


I want my account to set up users automatically, what do I do?


The

first step is to check that BOS knows who to set up as a user. BOS looks for a specific
entitlement attribute to signal that it can set up a user automatically. So you’ll need to firstly, check
that your institution can release entitlement attributes, and

secondly, check that you have an attribute
that can be released that matches your institution’s policy on BOS use. See <ref> for more details.


What if I don’t want BOS to automatically create users any more?

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
30

of
33

You’ll need to change this setting in your
Shibboleth control panel. If you switch off the facility for the
creation of users, it will become your responsibility to approve applications again.


Deleting users


What happens when a user leaves
?


As long as local processes are in place to disable
user access to your Single Sign On when they
leave, this will also prevent them from accessing BOS.


There may be circumstances in which a user still needs access to BOS. If this is the case, then they
will need to contact the BOS account PC, who will move

their access route from Shibboleth, back to a
BOS
-
based login.


What happens to a user

s account after they have left?


When a user leaves, if the BOS account PC does nothing to delete them, their account simply sits
dormant for a period of 6 months.


A
fter 6 months, the user becomes marked as ‘inactive’. Inactive users remain within a BOS account
for a further 6 months. They become eligible to be filtered out of views by the PC, or can be grouped
for view on their own. Their surveys and data are flagged

to those able to access it, and to PCs as
requiring attention before they are deleted.


After a further 6 months (so, 12 months after they last successfully logged in), the user, and any
surveys still attached to them, are automatically deleted from the a
ccount.


What happens to a user’s data if they leave?


If a user does nothing to pass ownership of their surveys to another user within the account before
they leave, their surveys will remain in the account under their own name for 6 months.


After 6 mon
ths, surveys are marked as belonging to an inactive user. Other users on the account who
can see them will be notified.


After a further 6 months, any surveys that remain attached to the original owner, will be deleted along
with the owner.


Can PCs delet
e users and data earlier?


Yes
-

Although BOS will delete users and data eventually, PCs can delete users and data from the
account at any point.


What happens to the data from a user if they are deleted by the PC


If a PC deletes a user then their surveys are marked as belonging to that user, but are immediately
added to the normal 6 month ‘inactive’ queue.


After a further 6 months, if they are not claimed by another user, then they are automatically deleted.


Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
31

of
33

P
ermissions changes for users



How do permissions settings in Shibboleth work?


Permissions are automatically applied by Shibboleth when a user logs in. BOS retrieves information
from Shibboleth about permissions and applies it automatically.


Users


Could

my permissions change from one log in to another?


Theoretically yes
-

since your permissions are set by your institution, you could find that your
permissions change between logins.


Will I still have access to my surveys?


Your surveys should be in a l
ocation that you can access. You shouldn’t have any problem accessing
your surveys. If you find that you can’t access them, then you need to talk to your account PC.


Will I still be able to control access to my surveys?


Yes
-

BOS applies ‘native’ access
settings (those set up in BOS itself) after reading the Shibboleth
-
mediated settings, so you can always add controls to surveys that you own.


I see things appearing and disappearing within the account… what’s happening?


If you’re seeing surveys and folders appearing or disappearing each time you log in, then don’t worry
-

it may be that the account PC is editing the permissions.

You only need to be concerned if the changes affect surveys that you have access to.


Primary

Contacts


How do I change permissions that come from Shibboleth?


If your account is inheriting permissions from Shibboleth, then it means that your institution is
releasing entitlement attributes that are mapped to permissions within your BOS account.

To

change these, you either need to:


1.

Change the way that the entitlement attributes are released.

2.

Change the way that the entitlement attributes are mapped to your BOS account, surveys and
folders.

How do I remove permissions from a user?


To remove permis
sions from a user, you will either need to:


1.

Stop your institution from releasing the entitlement attribute that provides them with that
permission, or

2.

Change the mapping of that permission so that it no longer provides the same access as
before.

How do I

add permissions to a user?


To add permissions, you will either need to:

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
32

of
33

1.

Ensure that when they log in, your institution releases the entitlement attribute that BOS
needs to see to give them that permission.

2.

Remap the mapping of the entitlement attribute t
hat they have, to ensure that it provides
permission as required.

Multiple account logins


Can I log into more than one BOS account at a time?


Yes
-

BOS will allow you to do this.


Why would I want to?


If you log into more than one account at a time,
then BOS will allow you to see the surveys from all of
the accounts in one view. This means that you can administer all of your surveys in one place, without
having to log out and log back in again.


How do I log into multiple accounts?


First log into one

BOS account
-

and then select ‘log into another BOS account’.


BOS will provide a login screen, which will allow you to put in your credentials.

If you successfully log in, then BOS will link your accounts together, and display all of your linked
accounts

in one view.


What if all my accounts are Shibbolised?


If you have access to more than one Shibbolised account, then when log in, you’ll be asked to go
through the normal Shibboleth login process
-

and authenticate with each institution as usual.


Will a
ll of my accounts remain open?


No
-

your accounts will remain visible if they have been linked
-

so you’ll be able to see them. But you
won’t be able to access them unless you log into them each time.


Once I’ve logged in, will they remain open?


To make
sure that your data is secure, each of your linked accounts will still operate under the same
20 minute time
-
out that they currently do. So if you access a second account, and then don’t do
anything within it for 20 minutes, you’ll find that you need to lo
g in again.


What if I no longer need access to an account that was linked?


In the same way as you can add linked accounts at any time, you can also remove them.


What if I can’t access an account that I had access to before?


If you should still be
entitled to see that account, then contact the account PC. If there are reason why
you should no longer have access e.g. you have moved departments within the institution,, then you’ll
need to delete the linked account.

Project Identifier: SIAES

Version: 0.1

Contact: d.hiom@bristol.ac.uk

Date: 05/07/2
012


Document title: JISC Final Report Template

Last updated: Feb 2011


v11.0

Page
33

of
33

Moving between accounts


How does S
hibboleth impact on my access to BOS if I move?


Before Shibboleth, your access to BOS was controlled by an account PC. This meant that, unless you
told the PC you were leaving, you could often continue to access the ‘old’ BOS account even after
leaving th
e institution that administers it.


With Shibboleth, your access to BOS is controlled by the institution that administers the licence
-

through authentication with their systems.


If you leave that institution, and your access to their systems is removed,
you’ll no longer be able to
access their BOS account.

This means that you can no longer continue to access an ‘old’ BOS account, and a ‘new’ BOS
account
-

so, if you need access to surveys, you’ll need to move them between accounts.


Can I move my own surv
eys?


No
-

although you create surveys, and collect data, the institution that administers the BOS licence
officially ‘owns’ the data and so exercises control over it.

You’ll have to have the cooperation of the account PC move the survey and data.


What
if I don’t want to move the surveys?


If the ‘old’ account PC thinks that you still need to be able to access their account, then they will
provide you with a non
-
Shibbolised login that you can use. That way, you’ll be able to continue to
access the accoun
t without needing to login with their central systems.


How do I move surveys?


If you have a legitimate need to move surveys, you will first need an account to move them into.

Once you have a destination account, then you’ll need to contact the PC of the
‘origin’ account, who
will advise you on what you need to do to have the surveys moved.