Hi everyone! Over the past year, there have been a series of blog posts about the changes occurring around login pages, as we work to move everyone to one of our standardized login page offerings. While there are many reasons we are working towards this, an important goal around the standardization is security. This is always on our minds, and we need to be able to deploy security features quickly and consistently across frameworks and clients. Because of this, a number of difficult login page transitions are coming up in order to meet these requirements. Our Current Status Before diving into the details, I want to start with an overview of where we stand today. Over 85% of all client sites are already using one of our accepted, standard login page options. These include sites using the Login Page Management tool (LPM), sites using an SSO solution configured with our CAS or superSAML tools (and LPM as their admin login), or sites using our new Hosted pages framework. So far, migrations to the Hosted pages framework has been happening behind the scenes, and you can tell you are one of these sites if your login page is located at <your_site>/d2l/loginh/. To note, this graph only includes clients on Continuous Delivery and hosted in the D2L Cloud. Of those clients completely using the new standard frameworks, the distribution of total logins looks like this:Most of the remaining sites that need to move to an accepted framework fall into three main categories: The site needs to be moved from shibboleth to the superSAML tool Our Implementation Team is making their way through this listThe site has an SSO front door, but is still using an asp page as their admin local login We will be reaching out to this group shortly about using the LPM tool for this instead (which you can start using today at <your_site>/d2l/login?noRedirect or <your_site>/d2l/local)More information about that can be found in this previous blog post: [BROKEN LINK]https://community.brightspace.com/s/article/Login-Pages-are-STILL-Changing-WhyThe site’s login page is highly customized and still needs to be moved to the new Hosted pages framework We will be reaching out to this group shortly with information on how their site specifically will be affectedRead on below for more details Clients Moving To Hosted Pages This blog post is to give more information about what those in Group 3 can expect. Hosted pages are similar to the legacy asp custom pages, but are written in HTML, JavaScript, and CSS. Each time an update is made to a Hosted page, a number of security checks and functionality tests are run against that page before it is deployed to your site. These pages are not located directly on the webserver, and there is no risk of recent changes reverting after a monthly upgrade. There are a number of security restrictions involved with Hosted pages, due to the dangers of third-party and externally-hosted CSS and JavaScript. We encourage our clients to be extra cautious about this when designing their own content, and after discussion with our Security Team we have created the following restrictions around Hosted pages:Not Allowed: Hosted pages cannot import CSS hosted from Shared Files or external locationsHosted pages cannot import JavaScript hosted from Shared Files or external locationsHosted pages cannot directly include HTML hosted from Shared Files or external locations Allowed: Hosted pages can link to pages in Shared files or client-hosted pagesHosted pages can import images from Shared files or client-hosted locationsExternal HTML can be iFramed If the source is the client's Shared Files, the iFrame must include the sandbox attribute What does this actually mean for me? When you are moved to a Hosted page, you will not see any change in how the page looks or functions. Each page goes through multiple reviews to make sure the conversion from ASP to HTML was seamless. However, your process for updating the page may be changing. For most remaining clients, this means we will be taking a copy of the CSS, HTML and/or JavaScript files currently stored in your Shared Files, and hosting them with the rest of the login page code. Updates to these files will then need to be made by contacting D2L. For clients currently hosting their entire login page in their Shared Files, we need to work with you on the best solution going forward. Depending on the situation, one of the other login frameworks may make more sense for you, or if multiple pages are involved, only the ones with login functionality need to move at this time. If you rarely make updates to this page, a Hosted page may still be the best option for you. We know security is important to you, and we appreciate your cooperation in these changes. Of course comments are welcome below, but if you’d like to get the conversation around your site’s specific login page started now, you can reach out to us directly. Otherwise we will be reaching out sometime in the next few weeks with details specific to you.
