Logging in Individuals versus Organizations with LoginToPortal

  • 2
  • Question
  • Updated 3 years ago
Hi,
I am working with a client that uses membersuite they recently found that when we were logging their members in through our site they were logging in as other members. We were using the api to call loginToPortal with their username and password in order to authenticate the user. We then would take the information from the response from loginToPortal and take the LocalID. This localID matches a user in our database. We would call our database with this localID to make sure the user is a part of our system. If that LocalID matches with a user we return that user and we log in to the membersuite side using a security token.

The issue that is occurring is when we call loginToPortal and receive the LocalID of the member signing in we are receiving their organizational data if they last logged in as an organization and we are receiving their individual data if they last logged in as an organization. The issue was an organizations localID was matching up with an individual on our sides localID and we would log in the individual. As a security patch we have simply added that if the response from LoginToPortal is an organization then we append the LocalID with a string, nullifying the login.

The issue is that the individual trying to log in has the right credentials, but since they last logged in as an organization they are unable to login to our site.
Our thought process is to log the user in the same way if the loginToPortal returns an individual account, but if it returns an organizational account we would like to get their individual LocalID and then log them in with the correct ID. If they do not have an individual account then we would not log them in. I would like to find the best way to get the individual LocalID. I would assume we would have to remove their current login status as an organization then log them in as an individual, but I was unable to find a good way to do that using your api.
Photo of Jared Ostendorf

Jared Ostendorf

  • 5 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 2
Photo of Michael DeBinder

Michael DeBinder

  • 507 Posts
  • 36 Reply Likes
I have tested this and I get back the correct PortalEntity for the login credentials entered each time. When an Individual's login also has access to log in as an Organization, that data is returned in a separate "AccessibleEntities" collection, but should not ever modify the PortalEntity data returned.

What I think you are running into is that an Organization Entity itself actually has login credentials that can be used to log in directly as that Organization. This is a completely valid login scenario on our side and you would not necessarily be able to map this login to a specific, unique Individual record very easily.

If you are correctly identifying Organization account logins and blocking them, that may be all that you can do other than communicating to users to make sure they are using their personal logins rather than the Organization login.

Can you provide me the Association involved and a specific Login Username that you have been having an issue with so that I can look into this further?
Photo of Jared Ostendorf

Jared Ostendorf

  • 5 Posts
  • 0 Reply Likes
Thanks for the quick response. We are currently identifying and blocking organization accounts so from a security perspective we are good.

What I am a little confused about is how the client would log in on our side as an individual versus an organization. Are there separate credentials for an organization login versus an individual login or is there just no way to tell over the API?

The organization is URMIA. The Username is dhauver@holycross.edu . The organizational LocalID is matching a user's individual LocalID.
Photo of Michael DeBinder

Michael DeBinder

  • 507 Posts
  • 36 Reply Likes
Organizations can have their own credentials in addition to their Individuals. In this case, that e-mail address is the login for an Organization. That e-mail address is also tied to an Individual, but that Individual appears to have a randomly generated login ID.

In our system the login IDs are completely separate from any other data related to the record. This is an odd case where someone has set up their personal e-mail address as the login ID for the entire Organization.

This seems like more of a process issue where credentials may have been manually generated outside of normal processes.

We would need to identify all of these incorrect logins and convert them manually such that the e-mail addresses are properly tied to the Individual Login and not the Organization. Running a quick search on their site I see about 25 PortalUser records with an "Owner.Type" of "Organization" that have what appears to be an Individual's e-mail address as the login ID.

There is really no way to automatically clean up this data, it would have to be done manually in conjunction with the user to reset passwords as required.
Photo of Jared Ostendorf

Jared Ostendorf

  • 5 Posts
  • 0 Reply Likes
So basically It is not normal for a personal email Address to be tied to both an organization account and an individual account? So if this data was cleaned up and everyone had their individual Email correctly tied to their individual account the LoginToPortal would send us the Individual LocalID by default?

Also how would we go about cleaning this us is this something that the Association would need to contact you about or what is the best way to fix this?
Photo of Michael DeBinder

Michael DeBinder

  • 507 Posts
  • 36 Reply Likes
Correct, this seems like an incorrect setup to me. Once you move the Login ID from the Organization to the Individual, when that ID is used to log in, it would be pulling that Individual.

They should be able to do this through the Console. They would need to change the Organization Login ID to something different, then set the Individual record to that e-mail address and then notify that user that they would need to reset their password for the new login. You may want to have them work with our support team to find the best way to accomplish this. Since it is only about 25 people, it does not seem too bad.
Photo of Jared Ostendorf

Jared Ostendorf

  • 5 Posts
  • 0 Reply Likes
Thank you for your help on this I really appreciate it!
Photo of tonchooo

tonchooo

  • 2 Posts
  • 0 Reply Likes
Write a comment...