I'd like to move my user data from OutSystems to a third party system, so that logons can be shared between OutSystems and other applications. I'm looking into using Auth0, and one of the reasons is because it has a Bulk User Insert feature which I think would simplify transfering the data across.

This feature requires data to be in a JSON file, as specified in the schme on this page. There are fields including the password salt, and also the hash algoriithm, which are required - but I can't see them in the User entity in OutSystems. Is there any way to get hold of this data?

Hi,

I would advice to let users in the target system, to which you migrate their accounts to, to do a password reset. That would overcome the issues of migrating a salted password between two platforms.

Regards,

Daniel

Daniël Kuhlmann wrote:

Hi,

I would advice to let users in the target system, to which you migrate their accounts to, to do a password reset. That would overcome the issues of migrating a salted password between two platforms.

Regards,

Daniel


Thanks. That's my backup plan - but it's not a great user experience, and lost users cost money, so I'd much rather import the passwords where possible. This data has to be available within OutSystems in order for it to be able to function, and Auth0 comes with a specific feature to take advantage of it - I just don't know where to get the data from.

I don't think the salt is accessible anywhere directly. They moved to sha512 from MD5 which was used previously. Maybe directly contacting the support folks might help here. If you get through , would appreciate if you report back the solutions here. 



Cheers 

Hi Dean,

I think Tushar is right, that is why I proposed the scenario of a password reset.

This is what one also has to do I believe when migrating existing users from an external system to OutSystems, as the hashed password is salted. The generated salted hash is dependent of the OutSystems Platform where the application is deployed since it is based on the license information (Activation Code and/or Serial Number).

Regards,

Daniel

Tushar Panpaliya wrote:

I don't think the salt is accessible anywhere directly. They moved to sha512 from MD5 which was used previously. Maybe directly contacting the support folks might help here. If you get through , would appreciate if you report back the solutions here. 



Cheers 


Thanks - it does seem that contacting support is going to be the only way forward. It will take a while (not a priority right now for the person who would have to initiate that request), but I'll report back here when I eventually get an answer.

Daniël Kuhlmann wrote:

The generated salted hash is dependent of the OutSystems Platform where the application is deployed since it is based on the license information (Activation Code and/or Serial Number).

Regards,

Daniel


Thanks Daniel. That is helpful, because the Activation Code and Serial Number are both available Service Centre, so that's a start. But there must be a user-specific element, too, otherwise two users with the same password would end up with the same hash code. (I tried this out, and this is not what happens!)

It seems like contacting support is going to be the only way forward, but thanks anyway.

Solution

Hi Dean.

I don't like the idea of revealing sensitive information like the encoding formula to people that ask for it.


Because you can keep both databases up simultaneously:

Check for user in new DB.

If exists, use log in.

Else, search in OS.

If valid, save in new DB.

After a few months or a year, you'll have all the users that matter.


It's not pretty, but is better than force everyone to reset.

Solution

Nuno Reis wrote:

Hi Dean.

I don't like the idea of revealing sensitive information like the encoding formula to people that ask for it.


Because you can keep both databases up simultaneously:

Check for user in new DB.

If exists, use log in.

Else, search in OS.

If valid, save in new DB.

After a few months or a year, you'll have all the users that matter.


It's not pretty, but is better than force everyone to reset.


That's definitely better than getting all the users to change their password. Thanks!

Nuno Reis

Do you mind if I pick your brain about how this could be implemented, Nuno?

It seems like Auth0 has a built-in feature called Automatic Migration which does exactly what you've described. All I'd need to do is to set up a "database" in Auth0 which wouldn't actually be a database at all, but would use some Node.js code to validate a user's password and get their details.

To get this to work, I'd need to provide some kind of API within OutSystems, which the Auth0 Node.js code could connect to. But I'm thinking that the OutSystems User_Login API probasbly wouldn't work, because once this is up and running, that API would use Auth0 to log in instead of looking in the OutSystems database.

So I'd need to create my own API. And in that API, I could use the EncryptPassword API, and compare that to the password stored in the User entity to make a decision as to whether the user could log in.

Does this seem like the right way to implement your suggestion? I'm feeling a little out of my depth here, but if I know that this is the right route then I'm sure that some more research will be enough to get it up and running without too much more trouble. Thanks!

I never tried it, but something like that should do the trick.

Because your login is no longer in the OS realm, you have to be creative and avoid Login actions. EncryptPassword works because we've seen it being used. You remember that login logic in some demo applications where it checks if admin is still with the default password? It's exactly that.


Nuno Reis wrote:

I never tried it, but something like that should do the trick.

Because your login is no longer in the OS realm, you have to be creative and avoid Login actions. EncryptPassword works because we've seen it being used. You remember that login logic in some demo applications where it checks if admin is still with the default password? It's exactly that.



Brilliant, thanks for your help. It's probably several weeks before implementation begins, but at least I've got some kind of road map now, so I'll be ready to get started when the time comes.