Resolved Errors installing RO Single Signon

Hello Eddie,

This is not a support section but a pre-sales section for asking questions about our products. Support is only given if you have an active membership and I don't see an active RO Single Sign On subscription in your name.

Since you don't have an active subscription I wonder how you came by our software. It is open source so no problem there but we cannot support non-members.

Hi, Roland,



I work with Laura Gordon at Rutgers University. We are testing this extension to see if it will work with Rutgers’ central authentication server. I’m copying
Laura on my reply.



Regards,

Eddie





From: RolandD Cyber Produksi <support@rolandd.com>


Sent: Thursday, July 30, 2020 4:36 PM

To: Edward Konczal <konczal@sas.rutgers.edu>

Subject: [#63545]: Errors installing RO Single Signon (Reply)

Yes, Roland, is there a way we can get support on the installation so we can test this out?

thank you!!!


-- Laura & team (Eddie Konczal, Michelle Martel, Stephen Kujan)

Hello Eddie,

Your post was without context for me hence my reply.

You are running an old MySQL version and I guess that is why it doesn't execute the query. You can manually create the table and see what the value should be for a DATETIME default value. This field does need this default because it is used for automatically setting a timestamp.

If the table already exists this will be skipped during installation, so that should finish then. Unless there are other incompatibilities with the old MySQL version, will find out soon enough when you install.

The other option is to use a more recent version of MySQL but not sure if that is an option.

Roland,
Hi, I will manually create the table, but more importantly, what version of MySQL do you recommend?

thanks
Laura

I found the issue...

1. We are on mysql 5.5, from mysql:
solution from mysql note:
The DEFAULT CURRENT_TIMESTAMP support for a DATETIME (datatype) was added in MySQL 5.6.
In 5.5 and earlier versions, this applied only to TIMESTAMP (datatype) columns.
It is possible to use a BEFORE INSERT trigger in 5.5 to assign a default value to a column

2. I adjusted the table by trying the code:
CREATE TABLE IF NOT EXISTS `#__saml_LogoutStore`
(
`_authSource` varchar(191) NOT NULL,
`_nameId` varchar(40) NOT NULL,
`_sessionIndex` varchar(50) NOT NULL,
`_expire` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP,
`_sessionId` varchar(50) NOT NULL,
UNIQUE KEY `_authSource` (`_authSource`(191), `_nameId`, `_sessionIndex`),
KEY `#__saml_LogoutStore_expire` (`_expire`),
KEY `#__saml_LogoutStore_nameId` (`_authSource`(191), `_nameId`)
)

this was created successuflly

3. but when the code is running, it still 'crashes, even if the table saml_LogoutStore already exists

To confirm, we need mysql 5.6 to use single signon?

thanks,
Laura

One more question, if we have MariaDB 10.2.31, what version specifically are you working under, I see:

COLUMNS table, a default CURRENT TIMESTAMP is displayed as CURRENT_TIMESTAMP up until MariaDB 10.2. 2, and as current_timestamp() from MariaDB 10.2. 3, due to to MariaDB 10.2 accepting expressions in the DEFAULT clause.

Hello Laura,

Correct MySQL 5.6 is good enough.

but when the code is running, it still 'crashes, even if the table saml_LogoutStore already exists

You get the same exact error? I need more information I am afraid than "it still crashes". It can hardly be the same error if the table already exists.

As for MariaDB, I have no experience with that but generally any version compatible with MySQL 5.6 should work as well.

Table on site:

JInstaller: :Install: Error SQL Invalid default value for '_expire'
Extension Install: SQL error processing query: DB function failed with error number 1067
Invalid default value for '_expire'
SQL =

CREATE TABLE IF NOT EXISTS `#__saml_LogoutStore`
(
`_authSource` varchar(191) NOT NULL,
`_nameId` varchar(40) NOT NULL,
`_sessionIndex` varchar(50) NOT NULL,
`_expire` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP,
`_sessionId` varchar(50) NOT NULL,
UNIQUE KEY `_authSource` (`_authSource`(191), `_nameId`, `_sessionIndex`),
KEY `#__saml_LogoutStore_expire` (`_expire`),
KEY `#__saml_LogoutStore_nameId` (`_authSource`(191), `_nameId`)
)
ENGINE = InnoDB
DEFAULT CHARSET = utf8;

Package Install: There was an error installing an extension: com_ro_sso_1.2.0.zip

Hello Laura,

The only thing I can think of is that the table prefix is incorrect because SQL won't execute the statement if the table already exists. That is why the create statement has the IF NOT EXISTS. Can you double check that the prefix is correct?

So since this is a 'public' display, I 'scratched' out the 'prefix', but yes, it's using the same prefix as all of our other joomla tables...and it has the same as the Database Tables Prefix in the configuration...

It's interesting that it's still trying to create the table...

I do see the tables:
xxx_sso_clients
xxx_sso_profiles
xxx_saml_LogoutStore

Could it be the 'capital' letters? that is tricking it?

I'm also looking into adjusting our mysql server to be MariaDB10... if we can't get it to work..

Hello Laura,

I did notice this is a public ticket but since you didn't start it I cannot make it private, otherwise you cannot access it

As for capital letters, MySQL should be case-insensitive. The one thing I am thinking of is that it tries to execute the query and already stops at the invalid syntax before it gets to the ignore part. As for the database creation, only thing I can think of is to remove the complete create statement from the sql file. Is that something you can do or do you want me to send you a modified package?

The SQL file is located in administrator/components/com_sso/sql.

Roland,
Thank you so much, yes we can 'remove' the create table from the installation script.

I'm going to speak with the team today, I think it would make the most sense to see how this runs on MariaDB10, this way we are using what we would use moving forward anyway. If we can't make that work, then I'll adjust the .php script, I'm just concerned that with an older version of mysql we could run into other issues.

thanks,
Laura

Hello Laura,

It does make sense indeed to see how it runs on Maria DB as you will be using that going forward.

Please let me know how things go.

Hi, Roland,



We have been able to install RO Single Sign On on a Joomla! website connected to a newer database server.



Here is what we (Laura Gordon) and I are trying to accomplish:



We would like to allow logins to Joomla! using our organization’s central authentication service. It supports both CAS and Shibboleth. Is there documentation
on establishing this type of authentication?



Regards,

Eddie









From: RolandD Cyber Produksi <support@rolandd.com>


Sent: Friday, July 31, 2020 4:46 PM

To: Edward Konczal <konczal@sas.rutgers.edu>

Subject: [#63545]: Errors installing RO Single Signon (Reply)

Hello Eddie,

As I mentioned to Laura earlier, I have no idea if it works with CAS. The extension was build based on using SAML, the underlying library (simpleSAMLphp) does support Shibboleth but I have not looked into that. So I am not sure if this works out of the box or not.

A regular setup has explanations on the Home tab when you go to Components -> RO Single Sign On. There is no user documentation other than that because a regular installation requires specific knowledge which generally means I need to install it. Single Sign On is not something that is plug and play I am afraid.

Hi, Roland,



OK…. If we need to get this to work, what should we do next?



-Eddie





From: RolandD Cyber Produksi <support@rolandd.com>


Sent: Thursday, August 13, 2020 3:43 PM

To: Edward Konczal <konczal@sas.rutgers.edu>

Subject: [#63545]: Errors installing RO Single Signon (Reply)

Hello Eddie,

I am afraid I cannot give any step by step guidance here because I never set it up using CAS or Shibboleth. The only thing I can think of is to try and setup it up as if it were SAML and see if the library detects Shibboleth and uses that. To do that, this means you are the Service Provider, so you can follow those steps as outlined on the Service Provider tab on the Home page as explained above. The refresh of the Identity Provider metadata can now also be done from the Identity Provider listing.

Hi, Roland,



We are working with the team at Rutgers that manages SAML/Shibboleth authentication. They are asking us the following:



The metadata we need from the Joomla sites should somewhat syntactically resemble the metadata file we provided for the Test Shibboleth server. Of course, yours will have elements specific to Joomla, such as the Entity ID, SAML endpoints,
optional signing/encryption certificates, etc.



There are some examples of service provider metadata at
https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataForSP#MetadataForSP-Examples





Do you know how we can generate such an XML file for a Joomla! website?



Thanks,

Eddie





From: RolandD Cyber Produksi <support@rolandd.com>


Sent: Thursday, August 13, 2020 4:20 PM

To: Edward Konczal <konczal@sas.rutgers.edu>

Subject: [#63545]: Errors installing RO Single Signon (Reply)

Hello Eddie,

The metadata links are specific to your site and how you set it up so I cannot give you the exact link but you can find it in RO Single Sign On. Go to Components -> RO Single Sign On -> Dashboard.

On the Tips & Information tab you will find all the Metadata links. The metadata link you will find under The Service Provider metadata URL is: and then Import that should be enough to give to them.