Search code examples
liferay-7shibboleth

Why does Liferay prefix password with algorithm name?


I looked at the User_ table in liferay and every new password has a prefix of:

{SHA-256}

I am trying to set up a Shibboleth IDP to use the User_ table to authenticate like this:

ShibUserPassAuth { relationalLogin.DBLogin required debug=true dbDriver="com.mysql.jdbc.Driver" userTable="User_" userColumn="emailAddress" passColumn="password_" dbURL="jdbc:mysql://mysql:3306/lportal" dbUser="root" dbPassword="password" hashAlgorithm="SHA-256"; };

However my authentication fails because the password does not match. If I go into the database an manually update the password, then it works.

Any ideas how I can work around this by getting Liferay to not set this prefix or getting Shibboleth to look for this prefix?


Solution

  • The answer to your question in the title probably is "because Liferay's history and upgrade compatibility". I guess they didn't want to alter the User_ table's schema, but needed a way to mark the hashing algorithm.

    I don't have the answer to your actual question, but two ideas:

    I found an old discussion that leads me to believe that you could write a query template for the Shibboleth DB connection (example copied from the linked discussion for longievity):

    <resolver:DataConnector id="mySIS" xsi:type="RelationalDatabase"
    xmlns="urn:mace:shibboleth:2.0:resolver:dc">
    <ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver"
    jdbcURL="jdbc:mysql://localhost:3306/userDB" jdbcUserName="root"
    jdbcPassword="root" />
    <QueryTemplate>
    <![CDATA[
    SELECT * FROM user WHERE usr_login =
    '$requestContext.principalName'
    ]]>
    </QueryTemplate>
    
    <Column columnName="usr_login" attributeID="uid" />
    <Column columnName="first_name" attributeID="displayname" />
    </resolver:DataConnector> 
    

    This example looks like you might be able to use SQL string manipulation functions in the query to cut off the preceding hash algorithm string.

    Another idea would be to create a View on the DB table that incorporates those SQL string manipulation methods, then connect Shibboleth to that View instead of the User_ table.