We’ve been sharing important communications regarding the upcoming OpenAthens certificate changes and the steps you need to take to prevent any disruption in access. While many have already reviewed and made the necessary preparations, we want to ensure everything goes smoothly for everyone. This Q&A is from a webinar we hosted, featuring guidance and a live Q&A session about certificate expiration.

Please be aware that the changes that could affect your access will occur on 3 February 2025.

Q: We're using Microsoft Azure or Entra as it's been renamed as our SAML based local connector for authentication into OpenAthens. Do we need to take any action regarding the upcoming OpenAthens Encryption certificate update? 

Generally, no action is needed. Azure does not encrypt its SAML responses to any service provider, including OpenAthens. Therefore, it doesn’t store our certificate for encryption purposes.  

However, if you have enabled the option to sign SAML request, there is a different area within Azure where you manage this. If you have added our certificate for signing purposes, you might need to add or update the signing certificate. But for encryption, no action is required.  

Q: Is any disruption expected through the UK Access Management Federation? Are you able to give us a heads up on any potential issues, eg. Where suppliers plan to switch at the last minute? 

We added the new certificate into the metadata we generated a few months ago, so it is available in the OpenAthens metadata. However, it won’t be included in the UK Federation metadata unless you request an update from the UK Federation.  

A few months ago, we sent some comms asking managing contacts to either email the UK Federation to update their entity or to add Matt Olive as an additional management contact so we could handle it for you.  

The only disruption we can almost guarantee is if your entity within the UK Federation has not been updated to include the new certificate alongside the current one. If both certificates are in the UK Federation metadata for your identity provider entity, there shouldn’t be any disruption.  

However, it does depend on the service provider you’re connecting to. The advantage of joining a federation is that both identity providers and service providers should adhere to common standards, regularly polling and refreshing the metadata. But this isn’t guaranteed if they are not part of a federation, so a service provider might not have the latest copy and this might cause disruption.  

Q: According to our records, our subscription for OpenAthens services is valid until June 2025. Could you please clarify why we received a notice stating that it will expire on February 3rd?

The expiration of your subscription to our services is different from the certificate expiration. The email you received is about the expiration of OpenAthens’ SAML signing and encryption certificates, which need to be updated by 12:00 UTC (UK time) on 3 February 2025.

OpenAthens uses SAML (Security Assertion Markup Language) to provide secure access to resources with single sign-on (SSO). The SAML signing and encryption certificates ensure your login process is secure.

Our certificates have a ten-year lifespan, and we are approaching the end of this period. We will be updating our signing and encryption certificates on 3 February 2025. For this reason, you need to make sure to update all copies of our certificates you are using by this date to maintain uninterrupted access to our resources. If the certificates expire without being updated, encrypted or signed information may become unreadable or untrustworthy, potentially disrupting the connection between your identity provider (IdP) and our service provider (SP).

Watch our webinar session for more information

Q: Is there an overlap between the expiry of the old certificate and the new one? 

Yes, there is an overlap. We generated a new certificate, which is already included in the metadata. The current certificate is set to expire on 24 February 24 at 9:20 AM UK time. The new certificate, which is already live, will be valid until April 2034. So, both certificates are currently in the metadata. It’s important to note that if the transition isn’t completed by 24 February, there could be disruptions, since there’s no buffer time. 

Regarding the signing, SAML can only sign with one certificate at a time. The OpenAthens identity provider will continue to sign responses to service providers using the current certificate until 24 February. Starting from Monday 3 February, we will begin signing some responses with the new certificate.  

For those using a local authentication system connected to OpenAthens and who have opted for us to sign request, we will start signing those requests with the new certificate on 3 February at 12:00 UTC, UK time. 

As for encryption, if your identity provider product encrypts responses to OpenAthens, you can continue using the old certificate until 24 February. So, signing will switch over on 3 February, while encryption can still use the old certificate until 24 February.  

Q: We currently have 2 certificates sitting on Alma, the current one and the new one. Should everything just move over seamlessly to the new one on the 3rd and we can remove the old one. I understand the current one doesn't actually expire until the 24th should we have until then to check?  

Yes, that’s correct. Starting on the 3 February, we will begin signing responses with the new certificate. Assuming the set up uses OpenAthens to sign in to Alma, the SAML response we sent to Alma will include all the necessary attributes and claims.  

From the 3 February, we will use the new certificate for signing. If Alma has both certificates, it will verify the response using the public certificate in the metadata. As long as both certificates are present, Alma should be able to validate the response without any issues. 

However, if any problem arises, you can remove the old certificate.  

Q: Is there any way to check without emailing OpenAthens? Or it that the update has happened. Is there a way to verify if the update has already been completed? 

Yes, there is a way to check, but it depends on your familiarity with the web tools like browser developer tools. These tools can help you see which certificate is being used by looking at the signature in the SAML request or response.  

We will start using the new signing certificate at 12:00 PM UK time on Monday. From around 12:15, try logging in to the service. If you encounter an error, it likely means the service provider hasn’t updated their system. If everything works smoothly, it means either:  

  1. They are not verifying the signature 
  1. They have updated their system with the new certificate 

Without using browser developer tools, it might be challenging to see if the service provider has made the change. But generally, if you don’t experience any issues, it means the transition has been successful.  

Q: The one Samo site already has no certificate attached. So will it be impacted? 

Assuming that this is a custom SAML resource. If you check the custom tab in the OpenAthens admin area within the resource catalog and see no certificate, it likely means the site doesn’t support encryption.  

To verify this, you can use tools like SAML Tracer or SAML Debugger in your browser. If the SAML response shows all attributes in plain text, it confirms that encryption is no supported. If encryption were supported, you would see cipher data, meaning all personal and sensitive information would be hidden.  

If there’s no certificate for the custom SAML resource in the OpenAthens resource catalog, it means the site doesn’t support encryption, and we won’t encrypt the response.  

When we send a response back to the service provider, we sign it using our certificate, which you won’t see in the catalog because it’s in our metadata. If the service provider supports encryption, we use their certificate to encrypt the response, and that’s the certificate you’d see on the connector.  

Q: Are sites using SIP2 authentication affected by this update? 

No, sites using SIP2 authentication are not affected by this update because we don’t support SIP2 as a protocol. So, anything using SIP2 is likely unaffiliated with us and connects to separate systems.  

If you have a custom integration developed by a third party, it likely uses the OpenAthens local authentication API to log you into OpenAthens. Since we don’t deal with SIP2, our certificates won’t have any impact on SIP2 connections.  

Q: If our vendors have already addressed it. Do we have anything to worry about? Can you tell if the vendors are set up correctly? 

If your vendors have already addressed this, you don’t have anything to worry about because we’re assuming that they’ve already addressed the issue. 

Unfortunately, there is no way for us to tell if they have already addressed it. This is very much low-level, under-the-hood stuff, which is why we’ve been trying to over-communicate. We don’t know if a vendor has the capability to consume two certificates or whether they automatically consume metadata, which they should, as that’s how SAML is designed. 

This is why, to reassure everyone, we’ve got all hands on deck on Monday in case anything goes wrong. However, we don’t foresee many issues, because in theory, if people are using SAML-compatible software optimally, there shouldn’t be any issues. But if there are, we’ll be on hand to help on Monday. 

Q: Is there a way to check myself, that these changes have been made by our it department by looking in the OpenAthens portal? 

This question relates to anyone with a local authentication system, specifically when using a SAML-based local authentication connector. 

If you go to Management and Connections within the admin area, you’ll see a connector labeled SAML, Azure, or CAS. These will be used for SAML. Nothing within the OpenAthens admin area will indicate if any changes have been made, as those changes would need to be made within your IT-managed system, which we don’t have access to. Therefore, you’ll need to liaise with your IT team to double-check if they’ve implemented any necessary changes. 

When it comes to local authentication connections, there are a few things that may need updating. These vary significantly depending on the software used internally to log into OpenAthens. 

If you go to Management, select the connector, and then go to the Advanced tab, you’ll see if you’ve enabled the signing of authentication requests. Some software requires signed requests. For this, your system will absolutely need to have our new certificate in place before the change on 3 February 2025. 

Depending on your software, you may be able to add the new certificate now in parallel with the old one. However, if your system can only store one certificate, the new one will need to be added after Monday, 3 February, at 12.00pm UK time. 

The other consideration is whether your system encrypts the SAML response to OpenAthens, which ensures that personally identifiable information (PII) is not exposed in the browser. In that case, the system will need our encryption certificate in place before 24 February 2025. 

If your system can store more than one certificate, you can add it now. If it can only store one certificate, ensure the new certificate is in place before the 24th. But, if it’s possible to add it now, there’s no issue doing so. 

Q: What needs to be done in order for Lexis and Westlaw regarding certificates?  

That would depend, they have multiple products. That would depend, but I’m fairly certain they’re in the OpenAthens Federation. I’d need to double-check the specifics, as I believe they have multiple products. Some are in the OpenAthens Federation, some are in the UK Federation, and some have 1:1 connections. 

However, regardless of whether it’s a “custom” SAML resource, a peer-to-peer connection, or whether the vendor is in the UK Federation or OpenAthens Federation, the key thing is that they need to have the latest metadata for wherever your identity provider is registered. 

If you use OpenAthens and you’re registered in the UK Federation, as long as your entity is updated in the UK Federation and the service providers have the latest copy of the UK Federation metadata, everything should be fine. 

The same applies if you’re using OpenAthens and are registered in InCommon. As long as your InCommon entity has been updated with the new certificate and the vendor or service provider has the latest copy of the InCommon metadata, everything should be fine.  

This same principle applies to the OpenAthens Federation. For any custom SAML resource or 1:1 type resource, as long as the vendor has the latest copy of your metadata in their application, everything should be fine. 

Q: We advised the UK Access Management Federation of the change in December. How long will it take for the metadata refresh to occur across the whole of the UK Federation will access be seamless for end users? 

If your entity within the UK Federation or the UK Access Management Federation has been updated to include the new metadata, how often a vendor or service provider updates their copy will depend on the service provider. 

Some may poll and update it every hour, others may check for changes and update immediately. Some may have a refresh cycle of 24 to 48 hours, and some may not update at all and require manual intervention. Unfortunately, there’s no way for anyone other than the service provider to know exactly when they will refresh their copy. 

The point of joining a multilateral federation like the UK Federation or the OpenAthens Federation is to adhere to common standards. The idea is that members regularly update their metadata, ensuring they have the latest information on other federation members. 

Typically, updates happen within 24 to 48 hours. However, there are occasions when you’ll need to contact service providers directly and ask them to update their metadata, especially if it seems they don’t have the latest version. Unfortunately, there’s no way for us to know with complete accuracy when a service provider will refresh their UK Federation metadata. 

Q: We use Entra integration of OpenAthens. So, according to the documentation, we do not need to take any steps. 

Generally speaking, you shouldn't need to do anything within Azure/Entra. 

For encryption by default, Azure doesn’t store any of our certificates. If you add OpenAthens as an enterprise app within Azure/Entra, it doesn’t store our certificates, meaning it doesn’t validate the signature or encrypt responses. 

However, there are opt-in configurations within Azure/Entra where you can enable the requirement for us to sign an authentication request. If that setting has been enabled, then you would need to update Entra accordingly. But if you’ve added OpenAthens normally, then no update would be required. 

Q: To update our SAML certificate within the UK Federation. Is it sufficient to simply point them to the metadata? 

That’s correct. We would recommend getting in contact with the UK Federation and stating, “As you’re already aware, our certificate is due to expire. Could you please update our entity to include the new certificate? Here is a link [insert link] to our metadata.” That should be sufficient. While the URL alone might be fine, providing a little bit of context can always be helpful. 

Q: If we don't have any SAML resources, do we need to do anything? 

No, but maybe it depends because it would be good to know why you use OpenAthens if you don’t have any SAML resources. Assuming you are using some SAML resources probably you don’t have any custom SAML resources or 1:1 connections. 

If you don’t have any custom SAML resources, in theory, there’s nothing you need to do. Any vendor that’s a member of the OpenAthens Federation should automatically have the latest copy of the OpenAthens metadata, as they should be refreshing it at regular intervals. 

However, we encourage you to keep an eye out for any issues that may arise on Monday and reach out to us immediately. While vendors should be updating the metadata regularly, some may not, which could cause issues depending on the software they’re using. 

One additional caveat: even if you don’t have any custom SAML resources if you have a local authentication system that uses SAML to log into OpenAthens, you may need to take action depending on the software you're using for that login process. 

Q: How can I be sure everything is set up correctly ahead of the upcoming certificate update, and what should I do if something goes wrong? 

We can understand the concern. We hope to have already done everything needed, but we couldn’t be certain. Unfortunately, the nature of technology, and specifically with certificates, means there’s no definitive way to be sure everything is set up properly until something changes. This isn’t specific to OpenAthens or any particular software; it’s just the nature of certificates.  

The key is to remain vigilant as things evolve. We're fully prepared and ready to assist when people reach out on Monday, but hopefully, everything will run smoothly. 

Q: When is the current OpenAthens certificate set to expire? 

As mentioned in our communications, the current encryption and signing certificate, since we use the same certificate for both, is set to expire on 24 February 2025 at 9:20 am UK time. 

However, while the signing certificate officially expires on 24 February, we will begin using the new certificate to sign any requests or responses from OpenAthens from 3 February at 12.00pm UK time. 

Q: What implications will this have for our end users? 

That’s a very interesting question. If everything has been updated correctly, then nothing needs to be done - everything should continue working as expected. 

The only potential issue could arise if a party involved in the process hasn’t updated something. In that case, an error may appear, likely stating something along the lines of: "Can't verify signature" or "Unable to trust this service provider/identity provider." 

If everything functions correctly, as we expect, there should be no impact on users at all. However, if a breakage occurs, the system will generate an error - at which point, please reach out to us, and we’ll help troubleshoot. 

Q: Will users experience any downtime or need to take action? 

End users, patrons, staff, and students, do not need to take any action. This update is entirely behind the scenes and not something users can configure or adjust. 

The responsibility lies with IT teams, systems librarians, and developers to ensure everything is updated within local authentication systems and on service provider or vendor platforms, so logins continue working smoothly. 

If all updates have been applied correctly, there should be no downtime. The only risk comes if certain systems require the new certificates and those updates haven’t been made, at which point, downtime could occur. 

Q: How can I communicate any potential disruptions to our customers? 

It depends on who your customers are. If you're a service provider, publisher or vendor, you shouldn’t need to send any communications - provided your system has been updated, has the latest copy of the various federations' metadata, and, if using 1:1 connections with OpenAthens customers, contains their latest metadata and certificate. 

However, if your system cannot consume the latest certificate for any reason and you need to make changes on the day, then it may be worth sending out communications. You could inform users that some administrative updates are taking place, which may cause minor disruption. That decision ultimately depends on you, your platform and any potential downtime. 

If the question is from a library or research center regarding end users, communication is not necessarily required. However, if you do wish to send something, just keep it simple - for example: 

"On Monday at 12.00pm UK time (or adjusted for your local time zone), some system changes will take place. If you encounter any issues, please contact [your support desk/helpdesk]." 

This also serves as a way to promote your helpdesk while acting as an early warning system. If any issues arise, we’ll aim to resolve them as quickly as possible. 

If users report issues that may be related to the certificate update, or if you're unsure, please do reach out to us, and we’ll help troubleshoot accordingly. 

Q: Are there any backup authentication methods if issues arise after the update? 

It depends on your setup. For example, if this was a library- esque customer, some organizations do have multiple connections registered to log into OpenAthens. However, if one wasn’t updated, the other wouldn’t be either. 

This is a case-by-case situation, so I’d recommend contacting our service desk via the support portal, or emailing them. Details can be found: https://www.openathens.net/support/  

Q: As a new member of OpenAthens. What do I need to know going forward, and what are the pros and cons? 

That’s a very broad question. Looking ahead, as of now, the next certificate update isn't due until 2034. However, we will always provide plenty of notice for any other changes. We have given as much notice as we thought was needed, and have been communicating with customers for months, but we are always open to feedback, and ways to improve, so as usual we’ll be conducting a retrospective to analyze what we could have done better and what worked well. 

These updates don’t happen often—it’s a fundamental part of the SAML infrastructure and provides security. As a provider of federated single sign-on services, we operate very much within the SAML framework, but these updates generally only happen every ten years approximately. 

Q: So, to confirm, this certificate change only impacts if you have a connection where sign authentication requests is checked

No, and yes. It depends on the situation. There are multiple ways to connect in and out of OpenAthens. If you have a local authentication connector registered in OpenAthens with "Sign authentication request" checked, then you must ensure your local authentication system has the new certificate. 

If it is unchecked, you don't need our new signing certificate. However, if that authentication system encrypts responses back to OpenAthens, then it will require our new encryption certificate. 

That’s only one part of the process. The first step is signing into OpenAthens to establish an OpenAthens login session. The next step is using OpenAthens to sign into other services. 

On service provider or vendor platforms, they may also require your new certificate. So, while you may only need to make changes internally, if you either encrypt responses to OpenAthens or have signing turned on, you may still need to contact vendors and service providers if they require the new certificate. 

Q:  When my organization set up access we just passed authentication URLs along to our E-resource vendors. Does that mean we are involved in the certificate process, or do the vendors handle certificates? 

Indeed, any vendor using SAML - so if you're using OpenAthens to sign into vendors via SAML, it is the e-resource vendor's responsibility to update the certificate stored within their platform. 

There's nothing you can do directly to update it yourself, other than prompting the vendor and asking them to update it. Generally, we've only advised organizations to contact vendors for 1:1 connections because the principle of federated access means they should already have the latest copy of the Federation Metadata. 

Q: What was the February 24th expiration date all about? 

That is the date our certificates expire—that’s what the date represents. The difference is that we’re trying to do things ahead of 24 February 2025, so that people have everything in place before then, rather than leaving it to the last minute, which can be risky. 

So, yes, that's the original expiry date and we're just taking steps in advance to ensure everything is ready on time. 

Q: How do you know if a resource is a SAML resource? 

When in the OpenAthens administration area go to ‘Resources’ > ‘Catalogue’ and any resource that does not say ‘custom’ or ‘proxied’ will be a SAML-based resource. 

Q: Will the existing certificate also coexist for a specific time period in case of any time span required to activate the SSO certificate from the shell side after you enable the certificate from your side?

If you are using the signing certificate, OpenAthens will start signing using the new cert at 12:00 UK Time on Monday 3rd February. If the service validates the signature and honours the expiry date, they must have the new certificate in their application alongside the existing certificate by this time.

Q: Will OpenAthens not be accessible while the new certificate is not configured?

If you’re using OpenAthens with a local authentication system (single sign on service), access will only be interrupted if your SSO system needs signed authentication requests and you don’t have the new certificate.

So, if your SSO system doesn’t have the encryption certificate set up by 09:20 UTC UK time, on 24 February 2025, access will be affected.

Q: How do I know if we are already set up for this or not? Is there an easy way to tell?

There is no easy way to tell before 12:00 UTC UK time, on 3 February for signing or 09:20 UTC UK time on 24 February for encryption. However, here are some indicators that could help:

  • If you are using a local authentication system that requires signed requests and you have our new certificate in place alongside the existing one, you should be good.
  • If you are using a local authentication system that encrypts its SAML responses and you have our new certificate in place you should be good.
  • If you manage a service provider and your system validates the signature on the SAML response and you have our new certificate in place alongside our existing one, you should be good.

Q: Could you share the pages where we can find all of the related materials?

You can find all the related materials on the following pages:

Q: Are the custom resources the only resources that require manual updating?

All SAML service providers should update their systems to ensure they have the new OpenAthens signing certificate. For members of the OpenAthens federation, we have sent communications to them. Resources that we do not have a relationship with and are set up as peer-to-peer connections are referred to as ‘custom SAML resources’. For these, you will need to reach out to them to ask that they update their systems.  Custom resources do not need updating, as these are just used to populate custom URLs within MyAthens+. You can check the documentation we prepared for further information on how to proceed.

Q: Are the vendor-configurated resources update on the back-end?

For access to vendor content using OpenAthens via SAML, yes, the vendor will need to ensure that they have the latest OpenAthens signing certificate in their service provider.

If you are signing in to OpenAthens using a SAML-based single sign-on system, you may need to get the team that manages that system to update it. If your SSO system encrypts SAML responses, it will need the new encryption certificate in place before 09:20 UTC UK time on 24 February.

If your SSO system requires signed SAML requests, it will need the new signing certificate in place in addition to the existing one by 12:00 on 3 February.

Q: Is it the signing certificate or the encryption certificate that is changing, or is there one certificate for both?

We currently use the same certificate for both signing and encryption so this will affect both.

Q: Does our campus IT need to update anything on their local SAML end?

It all depends on the software they are managing and how it is configured.

If your SSO system encrypts SAML responses it will need the new encryption certificate in place before 09:20 UTC on 24 February.

If your SSO system requires signed SAML requests, it will need the new signing certificate in place in addition to the existing one by 12:00 UTC on the 3 February.

Q: If we are updating OpenAthens metadata regularly (every 2 hours), do we need to take any additional action?

Some software does vary but in principle, that is correct.

Q: Will this affect all our e-resources and not just specific resources like EIU?

It may affect some SAML-based resources if the service provider/vendor has not updated their system to consume the new certificate.

Q: Should the certificate be with our IT department and a specific vendor?

If you are using a SAML-based single sign-on service to login to OpenAthens, then the answer is  yes. If that software needs to be updated it would be for your IT team to action.

Q: Can you show us some examples of how to update the certificate? Or how to locate the certificate to see if it needs to be updated?

This will vary based on the system/software you are using as each system is completely different. If anyone does encounter any issues on the day, we will be happy to get on a screen-sharing session to provide some best endeavours support in updating your system.

Q: If we check our custom SAML resources in the portal and the certificates have a date that is after February 2025 (e.g. Fri Dec 31 08:00:00 GMT-600 2049), does that mean we do not need to do anything?

The certificate shown on a custom SAML resource within the OpenAthens resource catalogue will be the certificate for that specific resource and is not affiliated with the OpenAthens certificate. You should still contact that specific vendor to inform them that they may need to update their system to add the new OpenAthens signing certificate.

Q: When I log in to OpenAthens dashboard, under the resource - custom tab- some of the resources under the </> SAML it gives me the error "Upload SAML 2 metadata via URL or file."  why am I getting that error?

That is a box providing information on how you can update the metadata that OpenAthens stores for an existing custom SAML resource. Refreshing the metadata for that resource will have no effect on the OpenAthens certificate change. It is that resource owner (vendor) that would need to update the information they hold about OpenAthens.

Q: What is the best way to test that the new cert is configured properly if the old one is still active?

There is no way to test ahead of the change as we will continue to be signing requests and responses using the existing certificate. We recommend testing after the change has been made at 12:00 UTC on 3 February.

With regards to local authentication systems encrypting SAML responses sent to OpenAthens. We will have monitoring in place to reach out to customers that have not updated their systems before 24 February.

If your software does not currently have an OpenAthens certificate, it is fair to presume that it does not use it.

Q: Can you give guidance on how we can confirm with the UKAMF that they have refreshed our OpenAthens metadata?

You could check the UK Federation metadata yourself or send and email to  service@ukfederation.org.uk.

Q: Is it correct that the SAML site handles the technical aspects, not us?

Yes service providers (vendors) are the ones that need to update the certificate on their end to ensure access to their platform via OpenAthens is unaffected.

However, if you are signing into OpenAthens using a SAML-based single sign-on system, the team that manages that system may also need to update it.

Q: How can we check if the new certificate is in use with 1) a custom OpenAthens resource 2) a UK Federation resource?

There is no way to test ahead of the change as we will continue to be signing requests and responses using the existing certificate. We recommend testing after the change has been made at 12:00 UTC on 3 February.

Q: Wouldn't there be a conflict if the signing uses the new certificate but the encryption still uses the old certificate?

There shouldn’t be any conflict as they are used for two entirely different purposes.

If a local authentication system encrypts the SAML response to OpenAthens, it will use its own signing certificate to sign the response.

If OpenAthens is signing a response sent to a service provider, we will use the service provider’s encryption certificate to encrypt the response.

Q: Do we need to ensure that only the custom SAML connections are updated? Will the ones available through OpenAthens be updated themselves?

All SAML service providers should update their systems to ensure they have the new OpenAthens signing certificate. For members of the OpenAthens federation, we have sent communications to them. Resources that we do not have a relationship with and are set up as peer-to-peer connections are referred to as ‘custom SAML resources’. For these, you will need to reach out to them to ask that they update their systems.  ‘Custom resources’ do not need updating, as these are just used to populate custom URLs within MyAthens+. You can check our documentation site for more information on how to do this.

Q: If we're only using the Auth API, is there anything we need to do?

You will not need to do anything within your application that utilises the API as that is not configured via SAML.
However, if you have any custom SAML resources, you should contact those service providers (vendors) to ensure that they have the new certificate.

Q: Will we get notified if anything goes wrong despite all our attempts?

Unless someone informs us, we will not know if something goes wrong. We cannot add monitoring to detect if something goes wrong with signing, as the error will be on either the local authentication system (if signed requests is enabled) or on the service provider (vendor) side.

Q: Where is the certificate uploaded once we receive it from you?

If you are operating a local authentication system (single sign-on system) used to sign in to OpenAthens, you will need to either refresh the copy of your OpenAthens metadata, or upload the certificate manually.

If you are a service provider with a SAML SP within a multi-lateral federation (OpenAthens Federation, UK Federation, InCommon federation), you will need to ensure you have the latest copy of the relevant metadata file(s).

If you are a service provider that establishes bilateral federation with OpenAthens identity providers, you will need to ensure you either refresh the individual IdP metadata or upload the certificate manually..

Exactly how and where you need to do this will vary depending on the software you are using.

Q: How do I identify 1:1 connections in my admin interface panel ?

Gounder Resources --> Catalogue. Custom SAML resources are identified in the catalogue with a 'SAML' tag.  You find more information about it in our documentation website

Q: Is there anything special that United States OpenAthens users need to know or do?

None of the communications or changes are geographical in nature. All the changes we have discussed apply to all OpenAthens customers, so please treat all the information provided as relevant to you.

Q: We have a custom IdP metadata xml (it's not an XML URL) in our SAML2 settings on Moodle. Is that ok?

Whether you have a static copy of the metadata, a metadata URL, or a certificate separately stored. The important action is to ensure that the new certificate is on your Moodle instance. In this case, you should download a fresh copy of your OpenAthens metadata and reuploading it into Moodle.

Q: Is Kanopy considered a custom resource?

Kanopy is registered in both the UK Federation, and the InCommon federation. If you are not members of either of these, then Kanopy will likely be setup as a ‘Custom SAML’ resource. To check, go into the OpenAthens resource catalogue and see if it has a ‘SAML’ label.

Overdrive/Kanopy are making the update on behalf of customers so there shouldn’t be anything you need to do.

Q: If we use LDAP as our directory service and don’t have the “advanced” tab, do I need to ask IT to update anything at their end?

The changes we have communicated are specifically to do with SAML so LDAP won’t be affected.

Q: Should we just update the certificates, or do we need to re-do the metadata file with OpenAthens?

If your system has a refresh option, this could be a good idea. There is nothing you need to do in OpenAthens itself, as any changes will only affect systems connected to OpenAthens.

Q: 1f we have custom OA resources, do we need to contact those vendors? If so, what do we need to send them to update—should it be a copy of our new certificate that our IT department has uploaded?

For custom SAML resources, you will need to reach out to them to ask that they update their systems to ensure they have the latest OpenAthens certificate (and/or metadata).  You can check our documentation website for more information on how to do this.

Q: We are a Service Provider who uses Keystone for all SAML Auth with our IdPs. Our SP Entity ID is federated, and a lot of our customer’s IdPs are also federated. However, we have 1:1 connections with some unfederated IdPs (who use Entra, BioKey). Do we need to do anything?

As a service provider using Keystone, you don’t need to take any action around service OpenAthens identity providers as we will ensure Keystone has the correct certificates. With regards to any 1:1 connections with any non-OpenAthens identity provider systems, there is nothing to do with them as they aren’t using OpenAthens and therefore will not be utilising our certificates.

Q: For custom SAML resources, what should we communicate to them?

Resources that we do not have a relationship with and are set up as peer-to-peer connections are referred to as ‘custom SAML resources’. For these, you will need to reach out to them to ask that they update their systems to ensure they have your latest OpenAthens metadata and/or the new certificate. You can check our documentation website for more information on how to do this.

Q: We checked our SAML configuration and looks no impact for us. But as we have non-prod and prod environments, did you update cert in non-prod environments already?

If you have lower-level environments for local authentication systems or service providers, you must ensure that their configuration has been updated. Unfortunately, we aren’t able to make these updates on our end, but we’re here to support you if you need any guidance.

Q: Can you clarify if we did need to update custom SAML connections

All SAML service providers should update their systems to ensure they have the new OpenAthens signing certificate. For members of the OpenAthens federation, we have sent communications to them. Resources that we do not have a relationship with and are set up as peer-to-peer connections are referred to as ‘custom SAML resources’. For these, you will need to reach out to them to ask that they update their systems. You can check the documentation website for more information on how to do this

Q: If we asked OpenAthens to make the UK Federation change for us, how will this be confirmed?

We can ensure that all of the OpenAthens IdP entities registered within the UK Federation have now been updated to include the new certificates.

Q: What will the error message look like?  Will it be from OpenAthens or the resource vendor?

If there is an issue on the service provider (vendor) end, then the error would be produced on their system.

Q: What would the signature be if we're checking for the new certificate in the browser development tools?

When looking in browser dev tools, you will see that we are signing requests using the existing certificate. From 12:00 UTC on 3 February we will start signing using the new one.

Q: I have some italian customers that have Sole 24 ore resource, as custom resource. In the tab certificate says "no certificate", should I do something?

The certificate shown on a custom SAML resource within the OpenAthens resource catalogue is specific to that resource and is not linked to the OpenAthens certificate. You should contact that specific vendor to inform them that they may need to update their system to add the new OpenAthens signing certificate.

Q: Is the 12:00 on Monday 2/3 mentioned, "PM" or "AM" and presume it is UK time?

It is 12:00 UTC on Monday 3rd February. So 12:00 PM, not 00:00 AM.

Q: We have added (to Alma) the new certificate alongside the one set to expire on the 3rd. If we encounter an authentication issue on the 3rd should we remove the old certificate?

Yes, and if you still encounter issues, raise a ticket with our service desk.

Q: I have already updated the X509 certificate in my SSO portal. I can only have one or the other, so I have the new one.  We are able to login with no issues. So does that mean we should be okay come Monday?

This suggests your service provider does not validate the signature on the SAML response, otherwise, access would be broken. So, it looks like you should be fine on Monday 3 February.

Q: We use EZProxy also, and users sign into the proxy using OpenAthens. Will EZProxy/OCLC have been sent the necessary certificate?

As this would have been setup as a custom SAML resource (peer-to-peer connection), you would need to reach out to OCLC to ask that they update their configuration. You can check the documentation site for further instructions.

Q: When do you expect this (certification expiration) happen again in the future?

The new certificate has a ten year lifespan and is due to expire at Apr 9 13:15:36 2034 UTC so it will likely be sometime shortly before then.  This has occurred before, approximately ten years ago.

It’s important to note that there could be other reasons for needing to change certificates. For example, advancements in computing power or break throughs in decryption might require stronger encryption. So, it’s something to keep in mind.

Rest assured, we are always looking for ways to make this process easier for our customers in the future.

Q: Haven't heard or seen any mention of resources that are labeled as "proxied" in the OpenAthens admin portal. Do we need to do anything with those resources? Or will they be updated by the vendor or OpenAthens federation?

The changes we have communicated relate to SAML based authentication. Proxy resources will be utilising IP recognition so no changes are required for proxied resources.

We are reviewing the questions from the webinar and will provide updates as we gather more answers.

Watch the webinar recording

This Q&A was generated from questions asked during our webinar. Watch the recording for more.

 

Watch the recording