John,

Just realized we never followed up with this.  Did you happen to try SAML
1.1.  Someone did point out a bug where we're actually generating SAML2
artifacts and not SAML1.1 artifacts (but its an easy fix to put on your CAS
server if that ends up being a problem).

Cheers,
Scott


On Wed, Jan 20, 2010 at 3:52 AM, Kooij, John van der <
[email protected]> wrote:

> Hello Marvin and Scott,
>
> First of all thank you for replying.
>
> To answer Scott first; we were planning on giving out our findings,
> lessons learned and such when we finish this project. We understand that
> Open Source can't thrive when people don't contribute. One of the
> additions we've made for instance is the extraction of encrypted
> passwords from a PeopleSoft database and checking them against encrypted
> passwords entered by the user logging in. Since PeopleSoft passwords
> can't be decrypted we were forced to do it this way (which is more safe
> anyway).
>
> As for SAML; if SAP were to do an assertion towards CAS with a ticket,
> wouldn't CAS be able to send an attribute back with the username (or any
> other value of interest) so that SAP then could do its internal party of
> authentication and authorizations? Or am I mistaken as to how SAML works
> in this setup?
>
> Maybe some more information is needed; We've setup CAS as our front end
> login form to users accessing PeopleSoft CRM. From within PeopleSoft it
> is then needed to access different HR systems using SSO. Those should be
> routed through CAS via serviceValidate or samlValidate. This works with
> PeopleSoft in combination with an HR product from PI-AG and the
> serviceValidate part of CAS.
>
> The options for authentication on SAP are;
> - SAP logon tickets (can only be issued by a SAP system)
> - SAML 1.1
> - HTTP Headers
> - Kerberos/SPNego
> - Client Certificates
>
> The first and last option are no options, those require either a SAP
> system or user actions to be able to get through, which we don't want
> with SSO.
> For a Proof of Concept we tried using HTTP Headers with an Apache
> webserver setup as reverse proxy. This did work but we don't have a
> sound feeling for the security of this solution and it doesn't go
> through CAS either. This goes around our goal in trying to achieve one
> authentication authority within this setup.
> This leaves SAML and Kerberos, which I am investigating now. SAML seemed
> the best option, research may prove Kerberos to be better. I don't know
> yet.
>
> Kind regards,
> John
>
>
> -----Original Message-----
> From: Scott Battaglia [mailto:[email protected]]
> Sent: woensdag 20 januari 2010 5:41
> To: [email protected]
> Subject: Re: [cas-user] multiple authentication methods
>
> John,
>
> As Marvin said, I'm not sure our out-of-the-box support would
> necessarily help you.  If you were willing to work with us (i.e. get the
> integration code contributed as open source) we could probably
> collaboratively come up with something that would work.
>
> Cheers,
> Scott
>
>
> -----Original Message-----
> From: Marvin Addison [mailto:[email protected]]
> Sent: dinsdag 19 januari 2010 15:47
> To: [email protected]
> Subject: Re: [cas-user] multiple authentication methods
>
> > SAP are not eager to make custom changes for SAP so I'm left with the
> > login modules that SAP provides. Out of these options the one with
> SAML
> > seems the best one, also because when we upgrade the PeopleSoft system
> > (in planning already), we can use SAML for that too.
>
> I am doubtful you'll be able to get SAP working by using the SAML
> support in CAS.  The primary reason that SAML 1.1 was added to CAS was
> to support attribute release and single sign-out for CAS clients.  I
> would imagine SAP wants to receive an AuthenicationStatement from CAS,
> which is not supported; CAS only sends AttributeStatements in response
> to a service ticket that is successfully validated at /samlValidate.
>
> What are the other integration options for SAP?
>
> M
>
> Please help Logica to respect the environment by not printing this email  /
> Pour contribuer comme Logica au respect de l'environnement, merci de ne pas
> imprimer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen
> Sie so Logica dabei, die Umwelt zu schützen. /  Por favor ajude a Logica a
> respeitar o ambiente nao imprimindo este correio electronico.
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to