Shibboleth & Oracle CRM On Demand

[Peter Schober]

* Nick Duan <nduan at verizon.net> [2011-12-07 05:20]:
> Like any enterprise CRM or ERP system, the user authorization is performed
> locally, not centralized.  In other words, user information is stored
> locally and each user is assigned to a specific role with predefined
> privileges to access certain information.  By locally I mean you have direct
> access to your enterprise directory service (i.e. LDAP or AD) from your CRM
> instance.  When user is authenticating with the system directly, the user's
> authorization role or access privilege is decided right away, so he/she can
> access the system resources directly (e.g. a sales manager can access the
> whole customer list, whereas an account manager can only access specific
> customer info).
> 
> But in case of Shibboleth or any internet-based SSO environment, direct
> access to LDAP is usually not possible, so even the user can get
> authenticated via a centralized Identity Provider (IdP), the authentication
> info (i.e. SAML assertion token) won't necessarily translate into
> authorization privileges on the relying party side (e.g. the CRM hosting
> server).

Unless you're talking actual federation (where access to another
insitution's LDAP server is highly unlikely), using SAML for authN
does not precluede the use of LDAP for other things (e.g. if the app
insists on getting data from an LDAP DSA).

If you can get the app to take data from SAML attribute (via a SAML
implementation in the application, or with help of Shibboleth and
environment variables/request attributes/request headers) you could
send the same things via SAML the app would otherwise pull from LDAP.

If you have the things in LDAP needed for authZ at the CRM/ERP system,
you can get them to the app via SAML. If authZ is happening/stored
locally in the application (based in the identity of the subject)
there's no difference whether you're logging in via LDAP or SAML or
something else.
-peter