IDG » Web Sign On

Re: Awareness: Applicant IT accounts

Mathew Mannion — Fri, 08 Nov 2019 13:44:43 GMT

If anyone is currently relying on the warwickcoursecode, deptcode, dept or deptshort attributes for these applicant accounts, please note that as of Wednesday 13th November these will change to reflect a department of "VX" and a course code of "APPL". These attributes are not currently reliable (due to them not reflecting applicants who may have multiple applications for different courses in different departments) so the change is being made to avoid any meaning being inferred from them.

Awareness: Applicant IT accounts

Mathew Mannion — Thu, 29 Aug 2019 15:17:54 GMT

Hi all,

As part of the launch of the Wellbeing Services system in January this year, we started to provision (restricted) IT accounts for applicants that appear in SITS. These accounts are not members of the University, students or staff, but can authenticate against web sign-on and you may see them appearing as authenticated users or in sentry results.

Example attributes for these accounts are:

student=false
urn:websignon:usersource=��TVADS
deptcode=CH
dn=CN=u1234657,OU=��TVApplicants,DC=ads,DC=warwick,DC=ac,DC=uk
title=Applicant
deptshort=Chemistry
member=false
id=1234567
warwickukfedgroup=Affiliate
warwicktargetgroup=Applicant
warwickcoursecode=UCHA-3
warwickyearofstudy=0
warwickitsclass=Applicant
staff=false
dept=Chemistry
warwickattendancemode=F
warwickukfedmember=N
warwickathens=N
warwickprimary=Yes
user=u1234567
urn:websignon:usertype=Applicant
firstname=Example
lastname=Applicant
name=Example Applicant

A couple of things to note:

There's no mail attribute, as these users do not have a ��TV email account until they transition into student accounts
These accounts exist even if the applicant does not accept or receive an offer to study at ��TV
The dn attribute doesn't include OU=��TV to signify that they are not members of the institution; if you use LDAP searches or binds this likely means the accounts won't appear there either

These accounts are created at the time that the applicant submits their application but are not necessarily registered by the applicant. In 18/19 there was no process that directed applicants to register their account at warwick.ac.uk/register unless they interacted with Wellbeing Support Services, but they may be encouraged more widely in the future. If the student doesn't receive an offer or declines an offer the account is deleted approximately 6 months after what would have been their start date.

Deprecation notice: GET requests passing tokens or credentials

Nick Howes — Wed, 02 Jan 2019 14:34:10 GMT

Last year we deprecated the use of GET requests to /sentry with requestType of 1 (token) or 2 (auth) for security reasons. We believe that all production apps that used to do this have since migrated to use POST requests instead, and so we are preparing to disable this kind of request altogether since it should have no impact on current running applications.

We plan to make this change on Wednesday 16th January. If you own an application with bespoke SSO integration you may wish to test login after 11.30am to make sure it works for you, and get in touch with us through helpdesk if there are any issues.

Re: Intention to remove: ��TVSSO cookie for non-HTTPS servers

Mathew Mannion — Mon, 26 Nov 2018 14:19:38 GMT

Following discussion with various impacted parties, this change has now been delayed until Monday 15th April 2019.

Re: Intention to remove: ��TVSSO cookie for non-HTTPS servers

Mathew Mannion — Fri, 16 Nov 2018 16:24:50 GMT

Adding the secure flag to a cookie when it sent from the server to the client instructs the client to only send the cookie back with requests over a secure connection. The flow looks something like this:

User signs in at https://websignon.warwick.ac.uk/origin/hs
https://websignon.warwick.ac.uk sends back a cookie, ��TVSSO=abcdef123456; domain=".warwick.ac.uk"; secure. The client's browser stores this cookie
Upon any subsequent request to https://...warwick.ac.uk/anything, the client's browser sends a header Cookie: ��TVSSO=abcdef123456

The reason for adding this flag is to prevent it being sent to any URL starting http:// to a domain ending .warwick.ac.uk. This is because the traffic could be easily sniffed by someone on the same network in order to steal someone's ��TVSSO cookie, which could then be used to impersonate that user.

Requests that are sent using Sitebuilder content feed pages will be unaffected if they are accessing a URL starting https://.

Re: Intention to remove: ��TVSSO cookie for non-HTTPS servers

Andrew Smith — Fri, 16 Nov 2018 16:04:02 GMT

Could you please provide a little more information about what impact you think your change might have? Is this adding functionality to make things work better, or tightening a loophole that could potentially prevent existing warwick servers being accessed in some way, either internally or externally? For example, I believe all our LAMP Servers are given a *.lnx.warwick.ac.uk address, and some of those also use the ��TVSSO cookie as part of validation from SiteBuilder. Will this be affected?

Intention to remove: ��TVSSO cookie for non-HTTPS servers

Mathew Mannion — Fri, 16 Nov 2018 15:44:52 GMT

It is our intention to add the secure flag to the ��TVSSO cookie that's scoped over .warwick.ac.uk. This would mean that if you were accessing a page over HTTP (e.g. http://myserver.warwick.ac.uk) modern browsers would not send the ��TVSSO cookie so it would not be possible to use this for authentication.

Please let us know if this would cause a problem for your services. Unless we receive a request to delay, it is our intention to start setting the secure flag from ~~Monday 3rd December 2018~~.

Update (26/11/18): This change has now been rescheduled for Monday 15th April 2019

Re: Sunsetting TLSv1.0 over web sign-on and other ��TV websites

Mathew Mannion — Fri, 12 Jan 2018 10:19:23 GMT

We have a new date for the third part of this change ("IT Services will disable TLSv1.0 connections to all other web services.") - this will now happen on Monday 5th March 2018. Amongst other applications, this will include:

Sitebuilder (the University website, including warwick.ac.uk)
MRM
Photos.��TV
WebGroups
PeopleSearch
��TV Search

Any server-to-server operations should be updated to use TLSv1.2 by this time. We will contact anyone who we're aware is currently using TLSv1.0 to inform them of this and advise them on upgrade strategies.

Following this change, on Monday 25th June 2018 we will update our configuration to not accept TLSv1.0 connections at all, instead of showing a page explaining why the connection hasn't been accepted. This will mean it is no longer feasible on this date to be whitelisted. Again, we will be in touch with affected parties.

Scheduled maintenance for web sign-on, web groups and web external users Monday 6th November 2017

Mathew Mannion — Fri, 20 Oct 2017 16:34:43 GMT

We need to perform maintenance on the database behind web sign-on, web groups and web external users. We intend to perform this maintenance on Monday 6th November 2017 at 3pm, and we think it'll take around an hour.

During the maintenance window:

Web sign-on: Users will be unable to sign in or change their account information in web sign-on for the duration of the change. Users who are already signed in to particular applications will remain signed in, but may not be able to sign in to applications they're not currently signed in to.
WebGroups: Read-only for the duration of the change. It won't be possible to create or edit membership of groups
Web external users: Unavailable for the duration of the change.

If this date and time is likely to cause serious inconvenience for yourselves or the users of your applications, please let us know as soon as possible so we can reschedule the change. Part of the changes we're making are intended to make it so that we don't need to perform this kind of maintenance in the future.

Re: Making WebGroups queries HTTPS-only

Andrew Taylor — Fri, 07 Jul 2017 15:09:08 GMT

Hi Matt,

Having just checked all of our calls to webgroups they all use https so don't worry about Economics or any "mydept" instance.

Andrew

Making WebGroups queries HTTPS-only

Mathew Mannion — Thu, 06 Jul 2017 13:11:06 GMT

We would like to make access to WebGroups over HTTPS mandatory. Currently, we accept requests to both http://webgroups.warwick.ac.uk and https://webgroups.warwick.ac.uk - this change will mean that all requests to the former will result in a 301 redirect to the latter.

For the most part, this change should be seamless. The query API is called typically via a HTTP GET so requests for (e.g.) http://webgroups.warwick.ac.uk/query/user/cuscav/groups will be seamlessly rewritten to https://webgroups.warwick.ac.uk/query/user/cuscav/groups with no appreciable change in performance. You can avoid the extra redirect by changing your applications now to go directly to the HTTPS version of the URLs.

This may have an impact if you have scripts that access the WebGroups API as the 301 redirect will mean the POST body of requests is lost. If you use the WebGroups API to manage groups, please update your scripts to point to the HTTPS version as soon as possible to avoid being impacted by this change.

Barring strong objections, we intend to make this change on Monday 17th July 2017.

Re: Deprecation notice: GET requests passing tokens or credentials

Andrew Taylor — Thu, 01 Jun 2017 14:18:51 GMT

Nick and Andrew,

All Economics systems have been updated. If any shared systems are in use by other departments these will also have been updated.

Andrew

Re: Deprecation notice: GET requests passing tokens or credentials

Nick Howes — Thu, 01 Jun 2017 07:43:05 GMT

Andrew P Smith,

We aren't changing any parts of OAuth so unless you are making a GET request to /sentry or /origin/sentry then you may not need to make any changes. We will keep reviewing the requests that Web sign-on is receiving and will let you know if a machine that you manage appears to be doing so.

Andrew Taylor,

That timescale is fine, many thanks.

Re: Deprecation notice: GET requests passing tokens or credentials

Andrew Smith — Tue, 30 May 2017 16:34:39 GMT

Hi Nick (& Andrew)

Although I have nothing critical at present using ��TV SSO (other than perhaps the Annual Leave system from Andrew Taylor which I assume he has/is checking).

I do have a system that used SSO and I may in the near future wand to use elements of again. This uses the oAuth functions I was given by ITS (or at least were wtote in PHP based on Java originals. These do appear to use a filter_input(INPUT_GET, 'oauth_verifier', FILTER_SANITIZE_SPECIAL_CHARS); function even though most of the later code does resort to POSTing parameters.

If it is this element of the Code that would not cease to function, may I ask what we might use in its stead?

The existing code does still appear to work. If it fails later, I might simply resort to using JSONP from within SiteBuilder, rather than using ��TV SSO to validate access to a website hosted externally.

Kind regards

Andrew P Smith

Applied Linguistics

Re: Deprecation notice: GET requests passing tokens or credentials

Andrew Taylor — Tue, 30 May 2017 15:53:00 GMT

Hi Nick,

We use GET requests on a number of applications. I'll do some testing on Thursday and have everything updated by the end of the week. Does that work within your timescales?

Andrew

Deprecation notice: GET requests passing tokens or credentials

Nick Howes — Fri, 26 May 2017 14:28:14 GMT

If you have hand-written code to make GET requests to /sentry with requestType of 1 (token) or 2 (auth), you will need to change this to make a POST request instead as we will be disallowing GET requests in future. The "token" parameter must be moved out of the URL query and into the POST body. Other requestTypes such as 4 and 5 (user lookup) are fine to request as a GET.

We'll try to contact most of the people who we know are making such requests, but we can't reliably detect every application so you may wish to review your code now to avoid any loss of service for users.

Sunsetting TLSv1.0 over web sign-on and other ��TV websites

Mathew Mannion — Wed, 22 Feb 2017 10:07:09 GMT

From July 2017, we will disable the TLS 1.0 encryption protocol across the University's web services. Disabling TLS 1.0 prevents it from being used to access ��TV websites via an insecure web browser or application. If your application connects to websignon.warwick.ac.uk or webgroups.warwick.ac.uk, you must ensure that the library you are using supports TLSv1.1 or TLSv1.2 for connections, or they will fail. You can try pointing your application at webgroups-dev.warwick.ac.uk now, where TLSv1.0 is already disabled.

When will this happen?

Monday 3 July 2017 - We will disable TLSv1.0 connections to our transaction tracking system, onlinepayment.warwick.ac.uk
Tuesday 1 August 2017 - We will disable TLSv1.0 connections to Single Sign-on and our identity provider. It will no longer be possible to sign in to web services using a browser that only supports TLSv1.0.
Monday 8 January 2018 - IT Services will disable TLSv1.0 connections to all other web services.

Although TLS 1.0, when configured properly, has no known security vulnerabilities, newer protocols are designed better to address the potential for new vulnerabilities. In order to remain PCI compliant for taking online payments, web applications that process or redirect to payment sites must have a plan to disable TLSv1.0 before June 2018.

This will refuse access to any user on a browser that doesn't have the more modern TLS 1.1 or TLS 1.2 protocols available or enabled:

Internet Explorer 8 (disabled by default; can be turned on via a settings change)
Internet Explorer 9 (disabled by default; can be turned on via a settings change)
Internet Explorer 10 (disabled by default; can be turned on via a settings change)
Android browser on any version of Android before 5.0 (available but disabled in Android 4.1–4.3.1, 4.4–4.4.4)
Firefox prior to version 27
Google Chrome prior to version 22
Opera prior to version 12.18
Safari prior to version 9 (i.e. in OS X 10.8 and before)

Users in a browser that doesn't support TLS 1.1 or 1.2, for whatever reason, will not be able to connect to any HTTPS web pages. Applications connecting to web sign-on or WebGroups will not be able to connect to the application if the language doesn't support it (e.g. Java prior to Java 1.8).

More information is available on our technical FAQ about disabling TLSv1.0

Web sign-on architecture changes (IP address changes) Thursday 22nd September

Mathew Mannion — Thu, 15 Sep 2016 15:11:30 GMT

We will be moving web sign-on to new load-balanced architecture on Thursday 22nd September from 11am. This will not have any publicly visible changes, but will involve a change in the public-facing IP address of web sign-on.

Old IP address: 137.205.247.145

New IP address: 137.205.28.35

Please ensure that any service you have that talks to websignon.warwick.ac.uk respects DNS changes in order for it to pick up the new IP address. Notably, Java 1.5 and earlier does not pick up DNS changes and caches DNS resolutions for the lifetime of the JVM, so if you run a JVM-based application on Java 1.5 or earlier you should plan to restart the application on Thursday 22nd September at midday. The old IP address will no longer work after Friday 23rd September and your application may exhibit issues where it appears unable to communicate to web sign-on.

This change is being made to improve the reliability and scaleability of the web sign-on application.

If you have any questions please reply here or contact webteam@warwick.ac.uk

WebGroups is moving to ID7

A guest user — Fri, 18 Sep 2015 11:05:36 GMT

From next week, WebGroups will have a fresh, new appearance. We are updating the style of WebGroups to match ��TV’s new brand.

The functions will remain the same in the new WebGroups, so you will not have to change how you are using it. You can create ad-hoc groups access control, email distribution, file sharing and so on, as always, using this tool.

Here is a preview of what it will look like.

Maintenance affecting Single Sign-on Thursday 3rd September 2015

Mathew Mannion — Tue, 01 Sep 2015 10:14:18 GMT

Please note that people who use your applications won’t be able to sign in via Single Sign-on (or access applications that they haven't already accessed in the same session) from 4pm to 4:20pm on Thursday 3 September 2015. If they are already signed in, they won’t see any issues. Also, WebGroups and the External Users system will be read-only during this period.

IDG » Web Sign On

Re: Awareness: Applicant IT accounts

Awareness: Applicant IT accounts

Deprecation notice: GET requests passing tokens or credentials

Re: Intention to remove: ����TVSSO cookie for non-HTTPS servers

Re: Intention to remove: ����TVSSO cookie for non-HTTPS servers

Re: Intention to remove: ����TVSSO cookie for non-HTTPS servers

Intention to remove: ����TVSSO cookie for non-HTTPS servers

Re: Sunsetting TLSv1.0 over web sign-on and other ����TV websites

Scheduled maintenance for web sign-on, web groups and web external users Monday 6th November 2017

Re: Making WebGroups queries HTTPS-only

Making WebGroups queries HTTPS-only

Re: Deprecation notice: GET requests passing tokens or credentials

Re: Deprecation notice: GET requests passing tokens or credentials

Re: Deprecation notice: GET requests passing tokens or credentials

Re: Deprecation notice: GET requests passing tokens or credentials

Deprecation notice: GET requests passing tokens or credentials

Sunsetting TLSv1.0 over web sign-on and other ����TV websites

Web sign-on architecture changes (IP address changes) Thursday 22nd September

WebGroups is moving to ID7

Maintenance affecting Single Sign-on Thursday 3rd September 2015

Re: Intention to remove: ��TVSSO cookie for non-HTTPS servers

Re: Intention to remove: ��TVSSO cookie for non-HTTPS servers

Re: Intention to remove: ��TVSSO cookie for non-HTTPS servers

Intention to remove: ��TVSSO cookie for non-HTTPS servers

Re: Sunsetting TLSv1.0 over web sign-on and other ��TV websites

Sunsetting TLSv1.0 over web sign-on and other ��TV websites