Forums - Thread Details
  • State Verified Answer
  • Replies 11 replies
  • Subscribers 321 subscribers
  • Views 2188 views
  • Users 0 members are here
Forum Actions
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.

Reply
  • 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.

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