Introduction:
In this webinar we will be discussing how to empower your users and staff to protect their privacy. Both presenters will be looking at Data Privacy from different perspectives:
Peter Reid from Bath Spa university will be exploring data privacy aspects of the individual users, and asking the question: why should Identity and Access Management be of interest to librarians? With an achievable level of technical understanding and some experience of supplier liaison, librarians can make responsible choices on behalf of users, confidently assert the terms of resource licenses, and create the starting point for empowering students and staff. With these new skills, librarians can reassert their professional role in protecting patrons' right to privacy.
Graham Mason from Overt Software will be exploring data privacy from the point of view of the resource. In this portion of the webinar Graham will be exploring how to protect the resource and its data from incorrect access and will demonstrate a little-known feature within Shibboleth called "context check intercepts" highlighted with a demonstration. Graham will be discussing how you can take a granular access approach using that feature to ensure only the right people have access to the correct resources helping to ensure security and license agreements.
Speakers:
- Mediator: Helena Slim (HS) – Marketer at Overt Software Solutions.
- Participant: Peter Reid (PR) - Digital Services Librarian at Bath Spa.
- Participant: Graham Mason (GM) – CEO of Overt Software Solutions.
- Participant: Chris Andre (CA) – CTO of Overt Software Solutions.
Webinar Transcript:
[00:00] HS: Hello everyone and welcome to today's webinar. Today we are excited to discuss some of the key concepts revolving around the topic of identity and access management, delving into the issues of user privacy and authentication. Before I introduce our guest speakers, I like to quickly inform you of a few housekeeping matters. Today's webinar is being recorded and we will be sharing the link with you via email. We really want this webinar to be as interactive as possible, so please take note of the chat box to the right-hand side of the presentation slides, where you can submit any questions. Q+A's will be addressed at the end of the presentations and questions we don't have time to address, will be answered directly by email. Lastly, we do have a quick survey for you to complete at the end of the Q+A's. We'd greatly appreciate if you took the time to fill out the review as your opinions will affect future events.
[01:02] Now I'd like to introduce to you our guest speakers. Today we have Peter Reid from Bath Spa University with us. Peter is a Qualified librarian, specialising, in the maintenance and development of library systems. He Configures, all library resources for online access, utilising SAML, federated and IP authentication as well as, granular access, troubleshooting and testing. Over the last 10 years, Peter has worked on the digital side of academic libraries, with a focus on Access Management in the last six. This has led to Peter’s collaboration with IT departments on many single sign-on projects.
[01:40] Our Second Speak is Graham Mason. With over 25 years of experience in the field of Identity & Access Management, Graham has been involved in several high profiles JISC funded Shibboleth projects, as lead, manager, and advisor. Graham Co-founded Overt Software solutions in 2010. Having previously spent over a decade in a variety of management, development and operational roles in the UK Educational sector. This experience has shaped Overt Software’s operations regarding its ethos, of exceptional service, and honest expert advice.
[02:15] And finally, we have, Chris Andre, CTO from Overt Software Solutions joining us today. Chris has been involved within the field of Identity & Access Management for over 10 years, developing and providing solutions to the FE & HE sectors. Chris will be supporting us with some of the more technical aspects of this Webinar, and all three of today’s webinar guests will be available to help answer your questions at the end of the presentations. At this time, I am going to hand the floor over to our first speaker, Peter Reid, who is going to start today’s presentation. Peter, if you’d like to begin...
Why is Identity ans Access Management of interest to Librarians?
[02:48] PR: Thank you very much for the introduction, Helena. And thanks to everyone for coming. Good afternoon. So as Helena said, yeah, I've been working in this area more and more over the past few years. I would be hesitant to class myself as an expert but in the keeping of the tradition of the accidental systems librarian, I found myself doing more and more work in this and becoming more and more interested. So, my purpose here is to share some of my thoughts and experience in this area; focusing on how librarians as traditional intermediaries can from a current position make responsible choices on users' behalf first. Confidently and robustly assert the terms of resources licences and establish grounds from which we can begin to empower our users in matters of ownership of data and privacy. So that's what I'm going to go through moving towards that end point.
[03:43] As you may have seen in the blurb, for this, we started with is 'why is identity and access management of interest to librarians?' specifically. So, the first and most obvious answer here is that we have traditionally upheld the maintenance of a patron's privacy as a professional duty. So, what I mean is there are robust statements from our professional associations, like the American library association, IFLA and CILIP, supporting this. But it's natural I think that as our role in managing collections is likely switched to that of custodian local content, to broker of access to subscribed content hosted elsewhere, that we have lost grounds somewhat I think that is a natural development.
[04:24] I think in a paper earlier this year that librarian and writer, Roger Johnfelled, who is the director of library and scholarly communication at Ethics SNR, asked the pertinent question, who is competing to own researcher identity? Now he listed the contenders as research gate, El server, Clarivate ORCID and also Silicon Valley giants, such as Google and Facebook. But notably he didn't include libraries or universities, this is strange initially from my perspective as researchers and students are members of the institution primarily, but just to quote from his paper he said; "the higher education sector remains absent from this landscape, we have seen no ground swell of effort to develop decentralised and or community controlled infastructures to enable research eccentric solutions". So that's the kind of point we are hoping to move towards, and although it's my focus here, I think that quotation shows that it is more than just protecting privacy, but about beginning to get to grips with a much wider challenge, and I think it would be a benefit to have more librarians involved. I think the challenge and the questions being asked demand a response. And I think the institutionalised IDP is a good place to start answering these questions.
[05:38] So Just, how and where to start? So, quoting from another writer Clifford Linch, who I recently learned formed some of the access management principles which really gave birth to federated access management in a white paper back in 1998, suggested "if you are using Shibboleth authentication to external content platforms, be sure to understand your organisation's attribute release policy first of all and the governance around the developments and maintenance of that policy". Sorry, that was from a more recent paper than 1998, that was from 2019. The question could be, what is that policy? Is it spelled out and articulated anywhere? And who is contributing to that conversation? I think in the case of university it's likely to be a contractual agreement, a registration which staff and students will sign which legally covers the prorogation of student data in university systems and third parties. But moving to that more user- centric point of view, in the context of the university, is that too liberal use of implied consent? The question falls down to finding out, what are we releasing? and to whom? in terms of the student data in regards to accessing resources.
[06:50] By taking a report generated from an example IDP we can visualise this. So, taking a sort of quality/qualitive scale visually representing privacy neutral general indicators of membership as green and more sensitive PII data as, I've done here, ever deeper shades of orange, we can see, in this example the UK access management federation there is getting a default attribute release, including some of that more sensitive data into a default bundle. Whereas, other SPs outside the federation could be getting those in addition to more sensitive data. So, something to look out for is that the policy and practice might be too liberal, data, which provided it doesn't need and has asked for being given away.
[07:42] I mentioned governance as well, Clifford Linch recommended understanding the governance around the policy. We are starting to see at Bath Spa more scrutiny from heads of compliance and legal counsel information security managers, in terms of what data is being transferred with specific reference to preference for pseudonymised ID's, in terms of student data, general call for transparency and demonstratable compliance as it relates to sharing data with third parties. And specifically, and of relevance to this talk in particular, detail of what data is transferred at the point of sign in? So, moving to the actual experience of using these web services.
[08:29] From my position as an intermediary and systems digital services librarian role, we've added several questions to the workflow for the acquisitions we need to consider when just talking about it with the providers about the new resources as we are setting them up. Asking questions, such as, are they asking for non-standard PII attributes, Such as email, first name, last name? Do they have a click through agreement? So, by that I mean where the data subject themselves further inputs information as part of registration with the system after they've authenticated and authorised, so when its already a condition of using the service. And about the privacy policy and data sharing outside the EU etc. So not necessarily things that are written into the contract at this stage but it's just something that is a bit of a ground swell towards.
[09:29] Establishing then, some grounds to begin making some responsible choices on the users' behalf; what could we do? Say with that default attribute release bundle I mentioned earlier, taking an example such as, Science Direct or in any SP really, you can see that not all of those attributes are required, are actually consumed by the SP. But information is given say in the UK access management federation available services available page about whether what attributes are needed, are they required, say no in the UK access federation there. I found REFFED's metadata explorer tool very useful, so for a different a different federation there you can see in the slide the actual metadata, and the attribute marked up there saying is it required, is it true? So you can see it and that's very helpful when that is included. That could be the basis for cutting back, so returning to the example I gave there, looking at the required attributers only UK access federation could do with only two there and just cutting back to a lot less really. So that something to do initially.
[10:37] I'm aware that not all universities, libraries or IDP address' institutions have as close a connection with part of the IT that manages its single sign-on services. It's an area of IT supply liaison and collaboration is where I've spent most of my career in libraries really. I think liaison in this area is important to library service in the same manner with which librarians have traditionally had to lobby within their institution for budgets, for places on the right committees, teaching liaison within schools and two things I've always found very helpful in this is taking an interest into how the technical stuff works, but perhaps not too much, the experts will do the rest and really try to build those relationships and face-to-face meetings are especially important for that really. Getting to know the people a little bit and maintain those ongoing relationships.
[11:36] A bit about the project where we actually migrated to the Overt IDP back in 2017, we've got some of the key players pictured in that photo I took a little while later there from Bath Spa. Yeah, the project manager invited the Overt staff for a site visit, I find it very helpful to meet the people, because we do have that ongoing relationship for configuration, troubleshooting, and testing, during the project and afterwards. And we faced a particular challenge during the project to migrate, particularly to do with those pseudonymised IDs I mentioned earlier. We've used them as a privacy standard, it's good to use, especially for services that depend on personalisation and the third-party user account to function, such as 'RefWorks' or 'EbookSupplys' which have notes and that sort of thing, and we found that we could not generate that unique pseudonymised attribute across the two IDPs. So, Overt wrote a script for us which did that, but it involved lots of testing, libraries, it's good that the library was involved because we understood the menus and the user requirement there, and we managed to make that migration pretty seamless, end-users didn't really notice, so I'd have to do things like talks to kind of raise awareness of it. But actually, the script that had maintained that third-party data on the services, we had to decommission it last year, so we had to get all of the suppliers who had done this, 'EBSKAR' and 'RefWorks', to update those unique user IDs at the same time on the same day when the script was decommissioned. This is a rather odd slide but it's showing the actual user names redacted there, old value and new value, the unnamed third value there but I think it was just, what I'm trying to say is it took a lot of work resolving all of these things, but we did do it, and the point I'm trying to make is that we could sustain the personalised memberships but it took that work and collaboration and finally.
I think it's better that the trade-off be diligence, for the library, for the institution that loss of privacy security for the user, had we used email or some other slightly more sensitive data the user IDs to maintain those accounts, it wouldn't have been a problem we wouldn't have had to have worked but it would have been slightly less of a balance, user ability privacy. So, that's just on example, of some of the work we have done.
[14:23] Now as I've said I'd like to move to a point, towards empowering users and actually informing them at the point of which they are signing into services. I was involved in a panel a couple of months ago, including a JISC student partner called Ganesh, but it's more from the publisher side and myself as a librarian talking about the issues of balancing usability with privacy. And one thing Ganesh said is "when the attributes of this information are shared, there needs to be an initial breakdown about where the data goes and why. Then students will know how important their decision is to publishers and libraries". So, it was kind of from an educational point of view really about understanding what is going on behind the scenes as a librarian. Libraries are involved in teaching, I'm interested in that angle of the digital literacy or ethics around this and making them a part of the experience but we're thinking of moving towards the consent form and having this at the point of which you have clicked into a database or one of your resources, just showing what attributes have been shared and giving the user some options there as to how they'd like to continue to be asked. So, it's not too different perhaps, I know we've got it on the web with cookies consent is a standard thing with GDPR. It’d be interesting to see from people who are listening what their thoughts are on this, we haven’t gone live with anything, but it would be a good thing to test, and as I said legal compliance and people are asking about this type of thing at this point, so, it may be something that we move towards.
[15:55] So finally, just ending my bit, that question I asked at the start, why is it of interest to librarians specifically? I think as the intermediary agent, which the IDP is between the reading material, the host institution, the university and the patron, that's like the librarian really, that's what we do. So, it's a good space to have that conversation around this, around the privacy debate, and analytics and that sort of thing if the institutional need is to maximise our ROI (return on interest) with analytics and that sort of thing, the IDP is crucial to have a kind of voice on there, getting that balance with privacy then the IDP is crucial too. My overall point is that it should be up to the profession and the institution to decide. I hope I've shared some useful things around our experience in that area. With that, I'll hand over to Graham.
Authorisation: Enhancing the User Privacy
[16:52] GM: Thank you, Helena. Thank you, Peter. As Peter's presentation highlights, making sure we only release the necessary amount of information to service providers thereby preserving user privacy is very important. Unfortunately, things can get missed and sometimes we might not be sure what attribute is required or being released, it can be a worry. So, in this section of the webinar, I'm going to be looking at things from a different angle, I feel I'm still achieving the same aim as Peter and at very least enhancing the user privacy by looking at privacy from an authorisation angle. What private data is being released by the user, thus preserving the privacy and only releasing the minimum amount of attributes is important, but what if you could stop that data being released and only allow the correct user access to the resource before it arrives at the service provider? Hopefully, I can convince you in this part of the presentation there might be another way.
[17:58] An important note, authorisation on the IDP happens before any attributes are released to the service provider thereby ensuring that the correct person has access to the resource. With this in mind, I believe I can enhance the user's privacy by taking a granular access approach. To make the case for a granular access approach and before Chris gives and action demonstration, my session will cover how you can control what users and their access to content; you as the IDP owner have the ability to make authorisation decisions and maybe granular access might provide you with a failsafe IDP authorisation mechanism.
[18:53] Some context to what I'm about to discuss in that I'm going to assume some expected responsibilities regarding the IDP and SP. So, point one, typically in a federated model the IDP should be responsible for the authentication of the users, and as Peter discussed only release the necessary attributes to the service provider. Point two, the service provider should then be responsible for the authorisation of that user, for example, the service provider should use the attributes that have been received to decide if the user from the organisation is allowed to have access to the resource and at what level. Point three, as Peter has highlighted, the IDP needs still try to make sure that make sure that the information being release to the service provider is accurate.
[19:42] Now this bit is fairly straightforward, and as my point two mentioned, in the previous slide, the server provider should use the attributes that have been received to decide if the user from the organisation is allowed access and at what grade level. Just a note here service providers are doing a wonderful job and will understand your needs regarding privacy and attributes so please don't think we have a problem with service providers. However, in my experience I've known service providers solely look just for an authentication and not making use of the federated attributes that have been sent to them. In other words they're just checking for a session. Another example, the service provider could be looking for the education scope affiliation attribute, however, because its a multi-valued attribute they might accept anybody that releases the, say the value member, and not make use of other values. This brings into question around this attributes specifying a person's wrong inside the organisation, and why I have mentioned member value.
As I pointed out member is part of a multi-value set of values within this attribute and it's intended to highlight a person' affiliation or affiliations within the organisation. For example, a learner is a member of the organisation and a student so will have the value student and member, teacher's have the values employee, faculty, staff and member, and as I've highlighted in the slide a person say a member of the non-teaching staff can fill several roles, for example, student, staff, employee and member values. Affiliates, alumni and walk-in libraries, indicate that the holder has some definable affiliation to the organisation.
[21:36] A potential hypothetical problem that might arise from this multi-value relationship, say your licence agreement specifies that only students are allowed to have access to resources, what if all staff and student uses the sceptre to release member as well as staff and student. For example, there could be a problem in this scenario, one successful authentication of a staff user, staff and member values are released to the service provider, however, because the server provider are only looking for member this allows the staff member in and thereby possibly breaking the licence agreement. So, a question I pose to ensure correct authorisation and peace of mind, could the IDP owner intercept the authentications? If you'll allow us to answer this question, we to make the following assumptions as the IDP owner and purchaser of the resource, you will know what licence agreement you have in place. However, as discussed, the service provider should be making authorisation decisions based off the attributes provided by the IDP, however, sometimes the service provider might assume or even require that the IDP owner makes authorisation decisions. Filter rules aren't enough, releasing no attributes is not sufficient as I've pointed out some service providers might allow access based on session alone.
[23:02] So, a solution to my question, would my granular access approach help me overcome some of the problems I've discussed? Yes, I think it might. And as the solution is possible free with the feature in Shibboleth and as the IDP administrator, you can make authorisation decisions on the IDP using context check intercept.
[23:29] What are context check intercepts, or briefly known as checks? Checks are used to interrupt and hold the process on the IDP before releasing any information to the service provider. Typically to use to make authorisation decisions on the IDP. There is a witty article and some great how-to guide regarding context check intercepts on the Shibboleth consortium site and the link below and also, we'll send it out when we send out the recording. So, these checks they track information about the requests, such as information about the service provider, information about the user, their attributes, the sessions or authentication stats, also environmental information, such as IP browser and much more.
This is all possible withinside Shibboleth and this feature can be implemented in a simple way such as checking values of an existing attribute, or you can make it as complex as a management interface with web service APIs. In my diagram here below, my time with my little check is activated when and entity ID of a service provider, in this case it's 'myid.com'.
Once that is activated the check then checks the IP address but it also checks the affiliation of the attribute and in this case it must equal staff. If it does then the user is allowed to authenticate to the SP. If not, unfortunately the authentication is halted. Chris will now demonstrate this feature and process in action. Thank you and I'll hand back to Helena.
[25:01] HS: Thanks Graham, Chris if you would like to go ahead?
[25:06] CA: Thanks, Helena. So, we're just going to quickly show you how the Context check intercepts can be integrated into a web application that allows end-users to easily make changes and create authorisation decisions on the IDP. So, we're just in our IDP dashboard here at the moment and I'm just going to jump into the granular access section, and this is the part where the context check intercepts into hooks into our API.
So, we can see we have a few rules here and I can delete those or edit them from the screen really easily. I'm just going to create a new rule for our EZPZ SP WordPress site, just for this demo.
So, I just click add new, and then I'm bought to this screen and I can give the rule a name and for the entity ID or the service provider this is actually where we put in all of the previously used entity IDs into a searchable list, so I can just search for EZPZ here and select that as the service provider and we can actually add multiple SPs here as well to make the rule apply to more than one resource, but we'll just keep this to EZPZ at the moment.
I then just add a comment to describe the rule and a little bit more detail so admins know what this rule is for and then I can either choose to go for allow conditions, where that will deny anyone access that doesn't meet the allow conditions, or I can create a deny condition which will allow everyone access apart from those that meet the criteria to be denied.
And under the condition we expose the ability to either match a single value, multi-value or you can go as powerful as you like with Regex patterns, and we can select the attribute on this side here as well.
For the moment I'm just going to add a deny condition to say that if someone account name equals my username 'CAndre', then don't let me in. And I'll just save that rule and that's instantly applied as we can see it's in the list below here. So, I'm not just going to attempt to access the EZPZ SP and go to the login page. And I'll be directed to the IDP to login and then we have MFA (Multi-factor Authentication) activated on our IDP so I'll just need to quickly pop in the OTP (One-time Passcode) token here.
And as you can see, I've been denied access before I even get back to the SP, we haven't left the IDP at this point, and this screen can be customised on the IDP to be more user friendly with contact information and perhaps a reason why the users not been allowed access today.
So, if I now just pop back over to the rule screen and change the condition from a deny to an allow, and again I'll just remove this deny condition and just select 'SAMAccountName' for the allow condition but this time I'm going to select a multi-value and add myself 'CAndre' and 'GMason' as allowed users, or allow values for 'SAMAccountName' to access the EZPZ SP, and all the other users will be denied account access now.
So, I'll just make this rule always require an MFA token session as well and then we'll try and access the EZPZ SP again.
Now this time I won't actually be prompted to log in to the IDP because I already have an existing session, I haven't closed my browser, and if we just log in here, we can see that I've been authorized access to the EZPZ SP and as you can see from the top right, I'm logged into the WordPress site.
And that was just a quick overview and a quick example of how the context check intercepts can actually be implemented as a full web service, rather than just scripts on the IDP. And I'll just hand back over to Helena now.
Webinar FAQ:
[28:33] HS: Okay, thank you, Peter, Graham, and Chris. And thank you to everyone for taking the time to listen to our guest speakers. As a reminder, if you have any questions that you haven't submitted yet please enter them into the Q+A section on the right and we'll get through as many questions as we can. So to begin with;
Would you use the attribute consent feature in Shibboleth, with all resources?
Would anyone like to take that question?
[29:04] PR: I could speak to that if you like Helena? I think, I suppose it depends on if that becomes a requirement, as I said there's more interest now, or scrutiny being shown, so I think we are in a period of regulation around these things with the GDPR, the California legislation that's gone through recently, and also not related to this, but the accessibility regulations and things like that. So, I think things like that there may be more of. I would sort of add the proviso that it would require kind of, I think, usability testing and that sort of thing, really just seeing how it works, making it simplified, not too intricate, making sure that it didn't make too much of a pain so, it just getting that balance with engaging students and a bit of testing to see, is it getting in the way? But, yeah, it's not a requirement at the moment but, from my understanding it would be, it's innkeeping with my understanding with were-they the regulations are pointing really, so I can see us doing more of a service and I think it would be on each resource in that case, yeah, if that happened.
[30:17] CA: Sorry, Chris here as well, just to add to what Peter is saying as well, I mean within side Shibboleth it's very easy to either blanket apply it to every single resource that's available or you can specifically apply it to specific resources. There's also the ability to hide certain attributes that may come up. For example, you may be quite happy with just allowing everybody that has this releasing edge opposing sides ID or persistent ID since it's pseudonymised, just let that through and don't even show that to the user cause it may confuse them for example. Whereas you want to show the PII attributes with first name, last name and email going out. So, you can definitely configure things to be more granular in that approach as well. The other thing as well, highlighting back to the, obviously it being a bit of an issue in the way that the process works, back on that screenshot you could see that there was three options as well, which will ask me again next time they log in, or only ask me again if the information changes, or never ask me again for any attribute information for any SP. So, the user has a few different options and really just gives them back that control.
[31:38] HS: So, there are some insightful answers there to that question. Moving onto the next question;
Would you still use the attribute filters with the context check interceptors?
[31:53]CA: I should probably take this one. So, the context check intercepts are a kind of, as Graham said before, it's a bot of a fail safe thing there, where we can definitely do the authorisation decisions on the IDP as a kind of first port of call or a last resort as it were. But you still would use the attribute filters with that, so, the filter is actually talking about really referencing what Peter's been talking about, where we are releasing specific sets of attributes, whereas the context check intercept is actually looking at it from an authorisation point of view, where we only want to allow people access to resource, who are allowed access to the resource. So, you'd use both, one to control what's released and one to control who is allowed to release something.
[32:50] HS: Alright, brilliant do any of the other guest speakers have anything else to add to that question?
[32:55] PR: I was just going to say, yeah it's, oh sorry Graham, but I don't know if I emphasised but I just see this whole scenario really, as being fundamentally collaborative, and I don't just mean internally within the university as a collegiate and member organisation, but with the suppliers, with providers of software like Overt and what Chris was saying is kind of meeting in the middle really I think, over this standard. So, I think it's very helpful to have that filter from both sides as Chris was explaining there.
[33:30] GM: Oh, I think we've go another question in as well Helena.
[33:32] HS: We do, yeah, so;
Roughly how many universities currently make use of the context checking intercepts?
And that is directed to our Overt guest speakers.
[33:46] CA: I'll jump in on this one and then if anyone else got anything to add. So, everyone has the ability to use them. I'd say, a large percentage, I'll go for probably around about 80/90% of our user base is now using the context check intercepts. Now as Graham king of pointed out, they can be in a very simplistic way, which is obviously just using a script that's on the IDP that's doing them or we can go through a full interface which allows people to set up rules as we showed on the demo. So, a large percentage of them are and that's just really because it's easier than going through filter rules and scripts really, through the interface. Yeah, so, I think about 80/90% of our customer base. I don't know if anybody's got anything to add to that at all? Graham?
[34:39] GM: Well I think why the subject came up many years ago is just peace of mind really; people weren't quite sure if somebody, they could be a walk-in library or somebody could have got on the WIFI and they weren't quite sure about the attributes, that they were accessing a resource that they shouldn't. So, really that's when these subjects came up but this context check intercepts has been in Shibboleth since 2018, and has also been updated for version 4 as well, so it's worth popping onto the consortium site and looking at the wiki article, because it highlights quite a lot. But, yeah, throughout the world I bet there are absolutely thousands of people using it.
[35:25] HS: Alright, fantastic! Thank you, Graham and Chris. Does anyone else have any other questions, you'd like to ask before we finish up this webinar? Okay, well in that case thank you for everyone for joining and taking part in our webinar today. Thank you also to Peter, Graham, and Chris for sharing your insights and expertise around the topic of Identity and Access Management. We do hope you found this webinar informative and engaging, please keep an eye out for our webinar satisfaction survey and email containing the webinar recording. Thank you for your time today and have a wonderful rest of the day. Goodbye.
