Internal Error when using OpenID connect after allowing acces to account

Tagged: , ,

This topic contains 2 replies, has 2 voices, and was last updated by  tomoko 5 days, 18 hours ago.

  • Author
    Posts
  • #18436
     tomoko 
    Participant

    Hi:
    I am trying to do the basic OpenID Connect configuration from pages like
    https://wikis.forgerock.org/confluence/display/openam/OpenID+Connect+Quick+Start
    https://wikis.forgerock.org/confluence/display/openam/OpenID+Connect+-+Curl+Commands

    After setup the OAuthProvider , and the agent, everythings works ok in one of my environments.
    I can do the login, the page requesting consent to the Agent is shown, and the redirection occurs, ok.

    But in another environment, after the page requesting consent I press Allow, it just shows “internal server error”.
    Checking log in the /debug folder in server, I see that in the file IdRepo file it shows:
    amSDK:08/11/2017 11:33:00:074 AM UTC: Thread[http-apr-8080-exec-6,5,main]: TransactionId[1e0b22f2-ccfc-4fca-af97-d51f8fda79b8-737]
    ERROR: JCEEncryption:: failed to decrypt data
    javax.crypto.BadPaddingException: Given final block not properly padded
    at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:989)
    at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:845)
    at com.sun.crypto.provider.PBES1Core.doFinal(PBES1Core.java:416)
    at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(PBEWithMD5AndDESCipher.java:316)
    at javax.crypto.Cipher.doFinal(Cipher.java:2165)
    at com.iplanet.services.util.JCEEncryption.pbeDecrypt(JCEEncryption.java:251)
    at com.iplanet.services.util.JCEEncryption.decrypt(JCEEncryption.java:149)
    at com.iplanet.services.util.Crypt.decode(Crypt.java:350)
    at com.iplanet.services.util.Crypt.decode(Crypt.java:375)
    at com.sun.identity.security.DecodeAction.run(DecodeAction.java:103)
    at com.sun.identity.security.DecodeAction.run(DecodeAction.java:64)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.forgerock.openam.utils.OpenAMSettingsImpl.decodePassword(OpenAMSettingsImpl.java:187)
    at org.forgerock.openam.utils.OpenAMSettingsImpl.getServerKeyPair(OpenAMSettingsImpl.java:144)
    at org.forgerock.openam.oauth2.OpenAMOAuth2ProviderSettings.getServerKeyPair(OpenAMOAuth2ProviderSettings.java:607)
    at org.forgerock.openam.oauth2.OpenAMTokenStore.createOpenIDToken(OpenAMTokenStore.java:253)
    at org.forgerock.openidconnect.IdTokenResponseTypeHandler.handle(IdTokenResponseTypeHandler.java:61)
    at org.forgerock.oauth2.core.AuthorizationTokenIssuer.issueTokens(AuthorizationTokenIssuer.java:105)
    at org.forgerock.oauth2.core.AuthorizationServiceImpl.authorize(AuthorizationServiceImpl.java:222)
    at org.forgerock.oauth2.restlet.AuthorizeResource.authorize(AuthorizeResource.java:156)

    The only diference I can think it is one of my environments (where it works) is using a separate OpenDJ as DirectoryServer ; and the one where is failing is using a embbebed internal OpenDJ of OpenAM.

    Any other ideas or checks, please?

    #18447
     James Phillpotts 
    Moderator

    Hi, this sounds like a known issue that should have been fixed in recent versions. Can you describe what version you’re using, and what your configuration is in more detail?

    Thanks,
    James

    #18482
     tomoko 
    Participant

    Failing environment:

    -OpenAM 13.0.0
    Checking a file it says
    “grep version serverdefaults.properties”
    com.iplanet.am.version=OpenAM 13.0.0 Build 5d4589530d (2016-January-14 21:15)

    -Apache Tomcat/7.0.75

    -Internal embbed LDAP in OpenAM.

    -OracleJDK 1.8 , also fails with OpenJDK

    -The openAM server has a UMA configuration done. Using an import import-svc-cfg with a config.xml operation.

    At start I thought it had something to do with the internal LDAP. But later, I discovered it is not the LDAP, because it works also with a fresh/empty openam with internal LDAP.

    Now I believe it has something to do with the previous UMA configuration I did (in another realm), and later export/import in a docker environment I do.
    It is posible to create a uma realm (that creates a Oauthprovider) and a basic OpenID configurator (that also creates a Oauthprovider)? Any conflict?

    Any ideas are welcome, I am a little lost how to isolate the misconfiguration/conflict.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

©2017 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?