Customer Portal - Password Policies

[Steven Cotterell]

Morning folks....

@Gerry, is there anyone that can give us a steer as to when we might be able to expect this functionality.

Our new customer is chasing has chased me twice on this since I visited them on Tuesday.

Cheers.

[Gerry]

Hi @Steven Cotterell

Its something we have in our backlog but we are really busy at the moment and have not got too much free capacity.  The issue is not so much with the timing out of the passwords themselves, thats relatively trivial, it's the behaviour of the system both before and after a timeout event. What is your expectation, are you simply looking to lock out an account after 'n' amount of inactivity, for example if not logged in for 60 days, reset password, or are you looking for the enterprise-style - your password is going to expire notices, your password has expired, please reset, please change your password before continuing etc...  There is quite a stark difference between those two ends of the spectrum

Gerry

[Martyn Houghton]

@Gerry

From our point of view, just the basic at this point so that policies are enforced. i.e. the a user logs in, if the password expiry date has passed, they must set a new password to continue the login process and access the customer portal.

Cheers

Martyn.

[Steven Cotterell]

@Gerry,

I agree with @Martyn Houghton here.

A password should have a configurable life duration. As this expiry date approaches a notification should be sent and/or if you login you should get an on-screen notification. After the expiry date you should be forced to change your password.  There should also be some settings that block people using the same password again to go alongside the other Password Policy settings.

Thanks for the response Gerry.

[Dave Longley]

@James Ainsworth @Gerry i would need this feature aswell.

[HHH]

@James Ainsworth @Gerry
Password expiry is not interesting to us with regards to external customers so that should be optional.
However force change on first login would definitely be good from an external customer point of view

[Martyn Houghton]

@Gerry

I see the password improvements have been made to the internal Hornbill User Authentication process including password expiry as per Platform update below. Is there any update on the securing the customer portal accounts as well?

Cheers

Martyn

 

[Gerry]

@Martyn Houghton

We looked at this at the same time as looking at the Employee portal. Unfortunately, the Customer Portal for guest accounts has a slightly odd implementation inasmuch as while every contact has a "login ID" field, if that field is empty it will also use email_1, email_2 and email_3 in that order to match against for user authentication.  Sadly, what we have found across our customer estate is email addresses are not unique in some cases, so there is no way to reliably implement the same level of functionality in relation to password expiry and resets because we have no solid point of reference for ID uniqueness. 

Our internal technical proposal is to change the way logins and password resets etc identify a contact, to ONLY work with the login_id property of the contact record and ignore the email fields, this would solve the issue as the login ID field in the database has a unique constraint so we can make assumptions about the uniqueness of the userID login credentials,  and this would allow us to move forwards while at the same time making the overall system more secure.  If we changed that logic now, the odds are good that some customers contacts will not be able to log in to the customer portal because their contact record would not have the login_id value set to their login ID.  

To address this we would need to spend quite a lot of engineering days writing code to detect all of these customer data issues and report them back to each customer so each customer can correct their data issues, and get them fixed before we roll out such a change.  Unfortunately the effort required just to do that is substantial, so the whole thing has been kicked down on the priority list at this time. 

 

Gerry

 

 

 

 

 

[Martyn Houghton]

@Gerry

Perhaps the way forward would be to provide a second authentication method using the the Hornbill internal contact database as the source but presented as a SAML interface back to it self as an SSO provider. This would also solve the issue where instances want to use mixed environment for authentication. Then only apply the new password controls on the SAML interface. 

This allows existing customer to remain as it, but allow those of us who want to move to a more secure authentication approach a way to move forward without having to ditch the contact database for a external system. This puts the emphasis on those who want to move forward to clean up and maintain their contact data rather than having to be done for everyone by Hornbill.

 

Cheers

Martyn

[Gerry]

Hi Martyn,

One of the plans we have is to separate out the identity and authorization schemes in the exact way you are describing, its well justified but quite a big change.  As part of the process of looking at our next generation UI we are looking at the SAML implementation, and as part of that we will probably be experimenting with a stand-alone IDP.

However, most customers that use the customer portal have this multi-login-id problem, so one thing you can do is to ensure that every contact that uses the customer portal has a valid login Id set, we are soon going to provide a switch that will allow you to enable only using this field. Once all customers who use the customer portal have switched this option on, that will be our trigger where we can make the changes we need to make. 

Thanks for the other email, I will respond this afternoon. 

Thanks. 

Gerry

[Martyn Houghton]

@Gerry

Is there any update on this?

Also can this be moved the CRM & External Customer Service & Support

Cheers

Martyn