Forums - Thread Details
  • State Verified Answer
  • Replies 11 replies
  • Subscribers 320 subscribers
  • Views 2184 views
  • Users 0 members are here
Related

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

Francesca Shiekh

Premise: I don't understand the first thing about how authentication really works.

We have our own in-house ERP application. (https://sugarclub.sugarcrm.com/engage/it-operations/b/share-your-story/posts/ah-the-possibilities)

Our ERP users are a subset of the our Sugar Users.

Our ERP uses LDAP for authentication.

Our sugar instance is set up to use LDAP for authentication.

Our ERP uses the Contacts, Accounts, Addresses etc from Sugar. So the ERP will be using SugarAPIs in the background to retrieve and sometimes upsert records.

We want our user on the in-house application to log into the in-house application AND get a Sugar API token at the same time (authenticating with their LDAP credentials and using a custom platform so they don't get kicked out of their regular Sugar session). And we want to preserve that token for the duration of their ERP session.

Any tips I can pass on to our ERP team on how to achieve this?

thank you,

FrancescaS

Parents
  • 0

    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.

  • 0 in reply to John Hawkins

    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).

  • 0 in reply to Francesca Shiekh

    Francesca,

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

    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.

  • 0 in reply to John Hawkins

    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.

Reply Children
No Data