Question for folks that use Shibboleth for their PeopleSoft environments.

[Bryan Wooten]

We use CAS with Peoplesoft. But I think the trick is the same.

You need to tweak sign on people code. Specifically we set up sign on
people code to use funclibldap.

We modded the people code to look for REMOTE_USER being set. If it is set
we flag the user as being authenticated.

There is some Peoplesoft panel that needs to be configured for this to
happen.

I am home right now, but if want more details / sample funclibldap code
let me know.

-Bryan

On 1/20/16, 2:48 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 1/20/16, 4:24 PM, "users on behalf of Ewing, Bill"
><users-bounces at shibboleth.net on behalf of BEwing at utsystem.edu> wrote:
>
>
>
>>We are working with a vendor to host our PeopleSoft environment and they
>>raised the following concerns out of the blue. My question is has anyone
>>took note of these bullet points in their setup of shibboleth with
>>PeopleSoft and would they be something for concern or would have a good
>>response to someone raising these? Mainly want to understand are these
>>valid concerns or more a factor of support documents not being updated
>>or oracle wanting to steer people to their own sso?
>
>It seems more like a left-hand, right-hand thing. Oracle has routinely
>directed people to use WebLogic's SAML support as an option with PS
>(together with OIF I guess), and though I'm not aware of anybody having
>used it, I wasn't aware they considered it "unsupported".
>
>> 
>>SAML support in PeopleTools 8.5x has a very specific and narrow use case.
>>
>>* Only SAML version 1.1 is supported.
>
>Yes, that's strictly about their web service stuff. As far as I know they
>allow and support use of external authentication using custom sign-on
>code, be it with WebLogic or with Shibboleth.
>
>>* SAML is not supported in PT 8.5x for external single signon. There is
>>no web access user authentication native implementation of SAML with
>>PeopleTools at this time.
>
>Strictly true.
>
>>We strongly recommend that customers do not implement custom SSO
>>solutions because of the many security compromises and business
>>continuity risks.
>
>PS lecturing anybody about security or reliability, that's funny. This
>from the company whose apps used to switch identity to SYSADM at runtime
>mid-connection (probably still do).
>
>But I would imagine they find it useful to discourage customers from
>doing anything they have to answer questions about.
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net