Problem in configuring SSO using SAML for applications hosted on diff m/c

Question

Hi Techies,
I am stuck in a weird problem for past month or so without any resolution. Not much help by googling. So I hope i get the answer from the mouth of the horses -
I am trying to use SSO using the sample application appA and appB as stated in the tutorial of SSO by BEA.
I am summarizing the problem below -
Steps followed for Configuring SSO using SAML
1. Created 2 domains on 2 seperate machines namely domainA and domainB
2. Source appliction is deployed on domainA and the target application is deployed on domaninB
The steps mentioned in the following tutorial has been followed-
http://dev2dev.bea.com/pub/a/2006/12/sso-with-saml.html
3. As mentioned in the tutorial the certificate is generated using keytool utility. The same certificate is copied
to WEBLOGIC_HOME/server/lib of destination machine.
4. The certificate was successfully registered on desitnation or host 2 but while activating the configuration
changes(SSL client Ientity Alias and SSL Client Identity Pass Phrase) for Federation services the following error
is thrown -
" SAMLBeanUpdateListener: SAMLKeyManager.prepareUpdate() failed with exception:
weblogic.descriptor.BeanUpdateRejectedException: SAML key Manage failed to validate key (SSL Client) configuration
in the FederationServicesMBean, key alias: testalias "
The interesting bit of the problem is that the same configuration works on 2 domains created on same machine. The
problem only occurs when domains are created on seperate machines.
Alterative to the problem: when the certificate is generated seperately for domainB and copied to
WEBLOGIC_HOME/server/lib, it works. However, the certificate generated in domainA should have been copied.
Note: I am using Weblogic portal 9.2.1
Any quick replies will be much appreciated. Thanks.
Edited by saurabh.agrawal at 02/06/2008 2:01 PM

Answer 1

Hi François,
You are right about the use of the NameID format. But the issue here is/was that OIF at SP is integrated with OAM, and the authenticated user at OIF-SP and OAM will be the Anonymous user rather than the user who was identified at the IdP even though the remaining attributes sent are for the IdP user. I think these attributes can be used by with OAM for authorization using custom authorization plug-ins but haven't tried that one out.
As for the attribute sharing profile, it's this one - http://www.oasis-open.org/committees/download.php/18058/sstc-saml-x509-authn-attrib-profile-cd-02.pdf, although for the life of me, I cannot remember why I suggested this in the first place!
-Vinod