avallen

Accordion

avallen

Activity

commented on OPENAM-1219

21 May

If you want to be sure to have the same behaviour as in glassfish 3.1.1, instead of removing
metro you can also downgrade it to the same version that was bundled with glassfish 3.1.1:

pkg uninstall glassfish-full-profile glassfish-full-incorporation metro
pkg install pkg:/metro@2.1.1-9

commented on OPENAM-1219

11 Apr

I can confirm that this solves the problem.

created OPENAM-1219, OPENAM-1082

28 Mar

commented on OPENAM-1012, OPENAM-460, OPENAM-454, OPENAM-199, OPENAM-469

17 Dec 11

commented on OPENAM-469

12 Apr 11

Hi Peter,

just this night I got a new bug report from a tester describing similar behaviour
after a SAML Login, followed by a SAML Logout, followed by a SAML
Login, which then repeatedly failed with
"HTTP Status 500 - Unable to do Single Sign On or Federation."

This against the latest release 9.5.2.

The stacktrace now refers to another line number, which fits exactly
with the source of the version in the openam_snapshot95_sustaining_branch:

java.lang.NullPointerException
java.util.Hashtable.put(Hashtable.java:394)
com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:646)
com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:123)
org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:112)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:386)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:91)

Note that given that this bug appears sporadically and for unknown causes, and also
might affect customers, I will additionally create a support case with Forgerock,
referencing this ticket so this gets analyzed with priority.

Cheers,
Andreas

attached 2 files to OPENAM-480

15 Mar 11

Attached you find the ssoadm merged debug log for OpenAM server and ssoAdminTools version 9.5.2 with the error that occurs when a site is defined and assigned to a server.

The following NPE that seems the likely cause of the issue was introduced with the fix for ~~OPENAM-332~~, rev. 456, see attached patch for a fix for this NPE.

amNaming:03/11/2011 12:33:38:451 PM CET: Thread[main,5,main]
Site Id Table -> {02=02, 01=02}
amNaming:03/11/2011 12:33:38:452 PM CET: Thread[main,5,main]
Platform Servers -> [https://login.haufe-lexware.com:443/auth]
amNaming:03/11/2011 12:33:38:452 PM CET: Thread[main,5,main]
Platform Server IDs -> [02]
amNaming:03/11/2011 12:33:38:452 PM CET: Thread[main,5,main]
ERROR: WebtopNaming.getServerId()
java.lang.NullPointerException
        at java.util.Hashtable.contains(Hashtable.java:265)
        at com.iplanet.services.naming.WebtopNaming.getValueFromTable(WebtopNaming.java:575)
        at com.iplanet.services.naming.WebtopNaming.getServerID(WebtopNaming.java:692)
        at com.iplanet.services.naming.WebtopNaming.getServerID(WebtopNaming.java:624)
        at com.iplanet.services.naming.WebtopNaming$SiteMonitor.<clinit>(WebtopNaming.java:1544)
        at com.iplanet.services.comm.client.PLLClient.send(PLLClient.java:145)
        at com.iplanet.services.comm.client.PLLClient.send(PLLClient.java:93)

ssoadm_debug_out, OPENAM-480_fix_NPE.patch

created OPENAM-507

28 Feb 11

commented on OPENAM-370, OPENAM-450, OPENAM-418

24 Feb 11

created OPENAM-469

09 Feb 11

attached one file to OPENAM-450

08 Feb 11

Please see the attached fiddler HTTP request and response log for a sequence of requests that causes this error.

I suspect that OpenAM's IDP has some confusion regarding its session.

See the response of the request /auth/debug/index.jsp for the session contents before the NPE occurs.

IDPSSOUtil_getAssertion_NPE.saz

created OPENAM-465, OPENAM-460, OPENAM-450

08 Feb 11

commented on OPENAM-435

31 Jan 11

Hi,

as I said in response to you mail on users@opensso:

"""
this NPE issue is already in Jira but still unfixed:
https://bugster.forgerock.org/jira/browse/OPENAM-370

The NPE is likely to hide the real problem, which maybe an
uncatched exception in the login module.
"""

Your _real_ problem might be that you do return null in the getPrincipal method.
I seem to remember that this will break the - undocumented - AMLoginModule
contract, which says:

if you return LOGIN_SUCCEED from your module, then this module instance must
return a non-null principal on subsequent getPrincipal calls.

Cheers,
Andreas

attached one file to OPENAM-305

28 Jan 11

Hi Viktor,

attached you find a module implementation that adopts an existing session, adding the constraint that it must be of a certain type. Some kine of constraint configuation would be necessary for a more generally useful module.

This module has solved our problems that we have with the current session upgrade mechanics, which by the way seem somewhat broken. Whereas in SAML they are now quite sane - upgrade mode is entered only if the requested authlevel is not fulfilled by the current session - the handling for normal logins is still lacking: upgrade mode is entered always if the requested service differs - modules and authlevels are not regarded.

So even if the existing session was established with the same module as the one that is performed by the requested authchain, upgrade mode will be entered and the user has to log in again.

The new module makes this fixable, but it shouldn't be needed in the first place.

Cheers,
Andreas

ExistingServicecloudSession.java

commented on OPENAM-208, OPENAM-370

12 Jan 11

commented on OPENAM-370

10 Jan 11

this can confuse developers quite some, as it hides the real cause of errors, please apply.

attached one file to OPENAM-370

10 Jan 11

attached the patch

LoginViewBean_prevent_NPE.patch

created OPENAM-398

10 Jan 11

commented on OPENAM-191

07 Jan 11

Just hit this error again from a bad client, cost me half an hour again to debug, would really be nice to fail early with a clear error message and exception.

created OPENAM-371, OPENAM-370

22 Dec 10

commented on OPENAM-305, OPENAM-191

05 Nov 10

created OPENAM-297

20 Oct 10

attached one file to OPENAM-269

01 Oct 10

attached patch of TaskModelImpl prevents the NPE and enables me to create fedlets again in spite of broken configuration.

PreventNPE.patch

created OPENAM-269, OPENAM-263

01 Oct 10

commented on OPENAM-261

28 Sep 10

Note that supporting the evaluation of the IsPassive value in an AuthnRequest is required by even the most basic of the SAML 2.0 conformance profiles (IDP lite). Implementations that do not support this cannot claim SAML 2 conformance.

commented on OPENAM-261, OPENAM-208, COMMWEB-17

27 Sep 10

created COMMWEB-17

03 Sep 10

attached one file to OPENAM-208

19 Aug 10

Please apply the patch, the fix is easy, the error hurts first-user experience in a big way in a product component that has been hailed as a big innovation ;-)

http://blogs.sun.com/superpat/entry/the_fedlet_best_innovation_award

web.xml-fedlet.patch

created OPENAM-215, OPENAM-208

19 Aug 10

closed OPENAM-176

12 Aug 10

created OPENAM-203, OPENAM-200

12 Aug 10

Atlassian FishEye repository viewer with Crucible code review. (Version:2.3.1 Build:build-482 2010-05-27) - Administration - Page generated 2012-05-24 11:11 -0400