By default when you sign out of Sitecore, you don’t get signed out of your Federated Authentication Provider (Tested against Sitecore 9.0). So if after you sign out, you try to sign in again, your Federated Authentication Provider still recognises you and doesn’t challenge you to sign back in again, and lets you into the system.
So have you really signed out, if you haven’t signed out of the Federated Authentication provider as well? IMHO - no.
If you log out of Microsoft Office 365, it also logs you out of Azure AD.
If you log out of Azure Portal, it also logs you out of Azure AD.
Also note, on the Azure AD sign out page, it also signs you out of Office 365, if you are signing out from another system. (That’s going even further, to an even more true single sign out where sign out of every system at once, but the sign out page has to know about all of the systems to sign you out of, beyond the scope of this post)
So can see it’s pretty standard behaviour when you sign out of a system, to also sign you out of the Federated Authentication provider as well.
Pipelines/Processor + Reflector = Win!
Starting with the Sitecore Launch pad.
The “Log out” button has some JS that fires “-/speak/v1/business/AccountInformation.js”. Which does an AJAX POST request to “/sitecore/shell/api/sitecore/Authentication/Logout?sc_database=master”. It then tries to parse the JSON result, and read the “Redirect” value. And then redirects the user client side to the specified url.
Serverside this “AuthenticationController” can be found in “Sitecore.Speak.Client.dll” “Sitecore.Controllers.AuthenticationController” “Logout” HttpPost method.
This in turn calls “Sitecore.Shell.Security().Logout” passing in an “Action
“Sitecore.Shell.Security().Logout” calls a pipeline “speak.logout”. This pipeline takes an argument of type “LogoutArgs”. “LogoutArgs” has a property “RedirectUrl” of type “UrlString”.
“RedirectUrl” is initialised before the pipeline “speak.logout” is called with “Context.Site.LoginPage”. And after the pipleline is called, the “RedirectUrl” value is used to send the client to the specified page.
The content editor on the other hand the “Log out” button calls onclick “scForm.postEvent(this, event, ‘system.logout’)”.
This triggers the processor “logout”. This also takes the same argument of type “LogoutArgs”, as the “speak.logout” pipeline.
If the “LogoutArgs” “RedirectUrl” property has not been set, it triggers a server side redirect to the “Client.Site.LoginPage”. See “Sitecore.Kernel.dll”, “Sitecore.Pipelines.Logout.GotoLogin.Process” method.
So to override the behaviour of logout going to the Sitecore login page. Adding a pipeline to “Speak.Logout” to set the “RedirectUrl”.
And adding a processor to “logout” before the processor “Sitecore.Pipelines.Logout.GotoLogin, Sitecore.Kernel”, to set the “RedirectUrl”.
We can control where users are redirected to on logout.
Interestingly when configuring a Federated Authentication provider, you specify on the “OpenIdConnectAuthenticationOptions” class the “PostLogoutRedirectUri”, but this isn’t used. Still we can reuse this configuration setting in our pipeline.
If you are using Azure AD, you can set the “RedirectUrl” to something like “https://login.microsoft.com/common/oauth2/logout?post_logout_redirect_uri=https%3A%2F%2fsitecore.local%2Fsitecore%2Flogin"
So it will log you out of Azure AD, then redirect you back to “https://sitecore.local/sitecore/login"
Obviously change the “post_logout_redirect_uri” parameter to match your environment.
With a few extra pipelines, and with the help of reflector, can achieve single sign out with Sitecore.
I’ve only tried this with Sitecore 9.0, and not with the new Sitecore Identity Server.
Pieter Brinkman put out this tweet after Sitecore Symposium, with some information about Sitecore 9.3, for those of us not able to attend Symposium and see his session.
#SitecoreSYM is a wrap, now time to fire-up that blog engine. A lot to share around the upcoming #Sitecore 9.3 release. As a gesture of good will -> the deck is now available on https://t.co/B9DqZ9CLot pic.twitter.com/B8Qy9kzLF0
— Pieter Brinkman (@pieterbrink123) November 12, 2019
I also saw him present the at the London Sitecore User Group where he explained this slide deck in some more detail.
Some highlights for me:
I look forward to seeing some benchmarks about the performance improvements, and what areas this covers. When I first read this I had thought this might mean Sql calls, but he explained at the User Group was referring to personalisation/tracking. Still he only listed out his top 5, and hopefully the performance improvements extends to other areas.
There is a footnote on Slide 35 & 36
“Media Library in Azure Blob Storage: Reduce the cost and increase the performance of storing media in Sitecore”
This is only listed for “PaaS” and the new “Managed Cloud”.
However I’d like to explore using Azure Blob Storage on Azure IaaS. Let’s see if this is possible when Sitecore 9.3 comes out.
I’d also like to find out if the Azure Blob Storage implementation just replaces the backing storage.
Or if it’s possible to serve the files direct from Blob Storage, bypassing the Sitecore Media library handler/disk caching on the Content Delivery servers. (Possibly with some other technology/thin API layer to provider resizing functionality)
Using Azure Blob Storage for the Sitecore Media Library for me is the most exciting development of Sitecore 9.3 that I’ve heard about so far, as could significantly reduce the size of the Sql databases.
Jammy Kam has customised Sitecore do use Azure Blob Storage for it’s Media Library before https://jammykam.wordpress.com/2015/12/01/sitecore-media-library-in-azure-cloud-storage-part-1/ https://jammykam.wordpress.com/2015/12/03/sitecore-media-library-in-azure-cloud-storage-part-2/
I wonder how similar the Sitecore implementation will be.
I’ve been following this update for Java for many months since initally seeing the popup warning when updating Java on my local machine. And now finally getting around to blog about it, now the options have become clearer. And finding that some people still aren’t aware about the pending update in January 2019 that will mean will require a commercial Java licence if you want any further security updates from the Oracle version of Java.
I brought this topic up at the Sitecore Discussion Club
http://sitecore.events/
When I started to follow this, the policy for the LTS release of Java 11 hadn’t been announced, and I was thinking would need to update to Java 11 to continue to get free updates. Solr is up to supporting Java 10 (since 7.3.0), however sitecore doesn’t support a version of Solr this high yet https://kb.sitecore.net/articles/227897, and anyway Java 11 is now not free anyway, so not an option to get free updates that way.
Further reading:
The cost has come down since I started following this.
Originally the price was:
Per CPU | Support | |||
---|---|---|---|---|
Java SE Advanced | $5,000 | $1,100 | ||
Java SE Suite | $15,000 | $3,300 |
Which is quite a large up front cost, and continual support cost.
Then it was announced the subscription licence, charging $25 per CPU per month with support. Going down to $12.50 with volume discount (possibly lower with Enterprise agreement), which works out cheaper than the previous licencing.
https://www.oracle.com/assets/cloud-licensing-070579.pdf
“Microsoft Azure – count two vCPUs as equivalent to one Oracle Processor license if hyperthreading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyperthreading is not enabled.”
If you’ve got 2 solr servers, and 3 zookeeper servers, all running as Quad Cores, that’s 5x4=20 CPU’s, which might be up to 20x$25=$500 a month. Or if the hyperthreading detail applies above, might ve $250 a month. And even cheaper if have a load of servers to volume licence. Would require Java licencing to confirm actual price for your particular scenario.
What the alternative’s to paying Oracle for commercial support?
Open JDK is the alternative.
https://blog.joda.org/2018/09/do-not-fall-into-oracles-java-11-trap.html
If you look at the docker community, most Docker images which use Java use an Open JDK variant.
(was saying DEPRECATED - This image is officially deprecated in favor of the Open JDK image, and will receive no further updates after 2016-12-31 (Dec 31, 2016). Please adjust your usage accordingly.)
https://hub.docker.com/_/java/
Shows previously issues/questions on legality of Java on Docker
https://blog.takipi.com/running-java-on-docker-youre-breaking-the-law/
Explains issues, and update on support now
https://devops.stackexchange.com/questions/433/is-there-no-oracle-jdk-for-docker
Flow chart of which OpenJDK to choose for Docker
https://medium.com/@hudsonmendes/docker-spring-boot-choosing-the-base-image-for-java-8-9-microservices-on-linux-and-windows-c459ec0c238
Update on Oracle Java support for Docker
https://blogs.oracle.com/developers/official-docker-image-for-oracle-java-and-the-openjdk-roadmap-for-containers
Official Java Docker images, but appears have to sign up to see them.
https://hub.docker.com/_/oracle-serverjre-8
This posts lists out the different flavours of the Open JDK
https://blog.joda.org/2018/09/time-to-look-beyond-oracles-jdk.html
Adopt Open JDK appears to be the main choice, with longer term updates, and actually free.
https://adoptopenjdk.net/
Red Hat are supporting it (and IBM which have now bought Red Hat)
https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support/
Amazon are releasing their own version of Open JDK, which they use internally, but still in public preview, but certainly one to look out for, and not just for use on AWS - can use off AWS which sounds awesome.
I noticed on this tweet that the version of Java Azure App Service was running was Azul.
https://twitter.com/dancruickshank/status/1072541500058284034
A quick google later I found that was announced in September, that if you are an Azure customer, can use Azul Open JDK for no extra cost. So that’s awesome too if you are an Azure customer, but this is just for use on Azure.
Ultimately you’ve got to way up the pros/cons for your particular scenario, pay a monthly fee to stay on official Oracle Java with security updates. Or switch to the Open JDK, and pick the variant which fits you well the best - and ensure your Java software is compatible with the Open JDK you’ve chosen.
It would seem if looking to move to Docker & Kubernetes eventually, then embracing the Open JDK seems to be the standard anyway. And even if Oracle engineers aren’t going to be supporting the Open JDK anymore, got a choice of Red Hat/IBM, Amazon and Azul (free on Azure) to go for.