Best way to log in a Sugar User from an in-house application via LDAP

Hey Francesca,

I am no expert either, but I believe that is how Single Sign On is supposed to work?

Does ERP only read from Sugar or it has to write data back too? If it is read only, consider using a separate account to pull data in. 

Regards,

Romney

ERP will also update / insert records, so we would like users to log in as themselves for audits to be properly labeled.

Francesca,

LDAP is not the same as Single Sign On ( https://jumpcloud.com/blog/sso-vs-ldap#cookie-accept ). LDAP is an authentication protocol which allows an entity to use a single point of authentication for all systems. That is not quite the same as having a user log on to your ERP and then also be automagically logged on to Sugar when they go to that GUI. For that you need to investigate SAML I think.

However, that is not your issue. As LDAP is the authentication protocol you are setting Sugar to use, I believe the API calls will also use it. As long as you have covered the "Create New Users" issue so that not all LDAP users can authenticate into Sugar then your devs API work should just revolve around using the LDAP credentials to authenticate, collect a token and do the CRUD you need.

I wouldn't get too hung up on trying to get a token immediately that will be preserved for the duration of a session as your users may not interact with Sugar at all during a session in the ERP. When they do, the token gets requested on first call (with, as you say, a custom platform to prevent cross-contamination), it can then be used until it expires whereby it can be refreshed / re-requested as needed. The API calls themselves should be created to do that part, it ought to be irrelevant whether the user is logged into Sugar separately as the API token request will be authenticating via LDAP on its own custom platform.

So in short, if you are using LDAP as the authentication protocol for Sugar then your ERP will be able to log users in for API calls with their LDAP credentials. If users also want to be in the Sugar GUI then they will log in separately, also using their LDAP credentials.

I hope that is right and that it makes sense :)

Thanks,

JH.

I understand that LDAP and SSO are not the same thing. What I'm missing is regardless of when we get the token, how do we get the LDAP credentials to the Sugar API call that gets the token?

Are you saying the ERP application will need to ask the user to re-enter their credentials for the API calls?

That's what we would like to avoid in order to have a seamless integration.

To be clear everything is on premise: ERP, Sugar, LDAP.

Not every LDAP user has a Sugar account
Not every LDAP user has an ERP account.
But every ERP user has a Sugar account (and an LDAP account).

Francesca,

Apologies, my first comment was as a response to Romney Lai's reply, not to advise you of the difference

Your scenario, as I see it, is that a user logs on to the ERP using credentials held in LDAP. That user will also have an account on Sugar, also authenticated by the LDAP record. That is quite a simple scenario so I hope I have it right.

What I would be looking at as a developer here is taking the credentials the user is logging onto the ERP with (as they log on) and making the API call to Sugar to get the auth token for that user as part of the process to log on to the ERP. The credentials will be the same because the Sugar authentication is also held in LDAP - as long as the user gets authenticated there, then no attempt is made to match with any password held in the Sugar database (as far as I know from previous experience) although I think the user names need to match. The token collected can then be kept (and refreshed if it expires) for the duration of the user session in the ERP.

The user should not have to enter credentials more than once as they are the same for both systems and the ERP should hopefully know what credentials have been used. So the development needed is at the login point of the ERP to also send a request to Sugar's API and store the token for use.

This seems a reasonably straightforward process to me though so I might have completely misunderstood what the scenario is!

A caveat here is that it is my understanding that the API token call uses the same authentication method as the UI log in and if that is LDAP then that is where it looks. Having not had to develop this before I am happy for someone to tell me I am wrong if that is so.

Apologies again for the original confusion. I hope this helps a bit.

Thanks,

JH.

Sorry, should have added:

The point about users logging in separately was only if they need to switch to using the Sugar UI whilst logged in to the ERP. In that instance they will have to log in again fully at the Sugar log in prompt - they will not already be logged in as if they were SSO.

Thanks,

JH.

The simplest solution is to use SSO for both the ERP and Sugar if possible.

If not, John's approach described below should work. It will involve coding but I know that won't scare you :)

Francesca Shiekh my suggestion would be to send data to Sugar from your ERP applications; I would suggest that you login to Sugar as a user account with Admin permission. Then use the SUDO API to become the user and you can CRUD data as the user without the user ever having to log in to Sugar directly.

Hey Francesca Shiekh,

Let me attempt to rephrase the requirements, to make sure I understood your needs. 

1. You would like the ERP integration to act on behalf of every single user, when connecting to Sugar
2. Both ERP and Sugar use LDAP credentials (either via Sugar LDAP integration or other means)
3. The integration from ERP to Sugar should not logout the Sugar users that might be logged-in to the ui and the users should not enter twice their password

Would the above three items cover your requirements?

The first question I have is: are you asking the question because the integration has no access to the credentials input by the user within the ERP? Otherwise probably there would not be a problem at all, as you could gain a token to Sugar there, as you would gain access to the ERP as well, and then keep the token refreshed. I assume this is the reason.

You could definitely try the sudo api with a POC. For v10.0 the documentation link is here https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_10.0/Integration/Web_Services/REST_API/Endpoints/oauth2sudouser_name_POST/ 

I recall it won't give you the exact same structure as a regular token AND user, so you might have to try it out first (hence why I suggested a POC). As you see from the guide, the sudoed token won't have a refresh token either, so you will have to gain a new one after expiration.

What you would do from the integration perspective is to login as the integration admin user to Sugar, with a separate platform, keep the token alive and then impersonate the users as needed. I can't recall now if the admin user is getting invalidated, or not, which will change the mechanics but the end-result would be similar.

Give that a go, and let us know how you went

Enrico,

You are quite right about the issue arising if the ERP does not have access to the credentials. In my reply I made the assumption (I know the old adage about assuming things!!!) that as LDAP requires the password to be sent in clear text to the server for authentication, the ERP (being developed in-house as per OP) would at least have this to be able to pass it to Sugar as well - even if it is not displayed / stored anywhere else.

I was hoping the solution can be as easy as that for Francesca's dev team. Fingers crossed :)

Thanks,

JH.