Dynamic Client Registration

[nynymike]

I was trying to get Dynamic Client registration to work. Here is the scenario:

I have two local VM's: one running the Gluu Server CE edition (hostname in my example ce.gluu.info), the other running apache (hostname: apache.gluu.info). I configured apache

            OIDCMetadataDir /var/lib/apache2/openid-client-creds
            OIDCRedirectURI https://apache.gluu.info/
            OIDCCryptoPassphrase secret

            <Location /protected>
                AuthType openid-connect
                Require valid-user
            </Location>

in my OIDCMetadataDir folder, I have one file ce.gluu.info.client:

      {
         "ssl_validate_server": 0,
         "client_id" : "apache.gluu.info",
       }

When I navigate to https://apache.gluu.info/protected, I am asked to enter my email address:

I wonder why this is necessary. If there is only one entry in the OIDCMetadataDir, why does it need to ask me? If I enter a new email address, it doesn't seem to create a new client entry in the OIDCMetadataDir

So anyway, after entering mike@ce.gluu.info, I just get redirected to https://apache.gluu.info/?target_link_uri=https%3A%2F%2Fapache.gluu.info%2Fprotected&iss=admin%40ce.gluu.info

Note: I don't see any dynamic client registration request on my Gluu VM, ce.gluu.info.

I was sort of hoping that the mod_auth_oidc would register in my OP, and that when I navigated to https://apache.gluu.info/protected ... I would be redirected to the Gluu Server login page... and then redirected back to the protected folder with the sub claim populated.

[zandbelt]

Hi Mike,

The .client file should not be created beforehand: after all Dynamic Client Registration would register and create this file itself. I believe that could be blocking, the logs may show that. Please try with a global setting OIDCSSLValidateServer Off added to your config and no .client file.

[nynymike]

Ok, now its registering. Also my redirect URI was not in the protected folder. Does the redirect_uri actually need to exist on the file system? If so, what should be in this file?

I see some other weird problems now. The first time I logged in, it worked, and I could see the sub value populated as the REMOTE_USER variable. However, on subsequent access attempts, I was seeing 500 errors. I see these logs:

[Mon Jun 01 18:38:37.102606 2015] [auth_openidc:error] [pid 18809:tid 139647262893824] [client 192.168.177.1:62001] oidc_unsolicited_proto_state: could not parse JWT from state: invalid unsolicited response: [src/jose/apr_jwt.c:173: apr_jwt_base64url_decode_object]: JSON parsing (json_loads) failed: unable to decode byte 0xac ( \xac\xf4\x85C\xd2\xa3\x96\x02\xc6I\x90\xf3\t80\x8aM\xf1\xea)\n, referer: https://apache.gluu.info/protected/cgi-bin/headers.cgi

[Mon Jun 01 18:38:37.102629 2015] [auth_openidc:error] [pid 18809:tid 139647262893824] [client 192.168.177.1:62001] oidc_authorization_response_match_state: unable to restore state, referer: https://apache.gluu.info/protected/cgi-bin/headers.cgi


I'll try to reproduce this exact scenario. I was trying it from both Chrome and Internet Explorer.

[zandbelt]

In the docs here https://github.com/pingidentity/mod_auth_openidc/blob/master/auth_openidc.conf#L8 it is explained that the redirect URI does not need to exist.

The invalid unsolicited response would occur if a response comes in on the redirect URI that cannot be correlated to a request because no mod_auth_openidc_state_* cookie could be found that does so. Typically that happens when the back button on the browser is used to a point where it replays the authorization response (that was successful earlier).

Another reason may be that cookie path/domain settings don't add up but I believe this situation would have been caught by the configuration checks at startup.

[nynymike]

Hans,

Not trying the back button B-)

When I hit the protected URL from Chrome, it works. Although when I return to the protected site, it re-prompts me for discovery.

However, when I GET the URL from Internet Explorer 11, I see a 500 Internal Server Error. The logs are below:

[Mon Jun 01 23:20:11.993997 2015] [auth_openidc:error] [pid 18808:tid 139647229323008] [client 192.168.177.1:54851] oidc_unsolicited_proto_state: could not parse JWT from state: invalid unsolicited response: [src/jose/apr_jwt.c:173: apr_jwt_base64url_decode_object]: JSON parsing (json_loads) failed: unable to decode byte 0xda near 'M' (M\xda;\x91\xddTN\x1e\xf3\x1d\xa0\x872\x8c{\x9a\x93/\xf4\xce)\n, referer: https://ce.gluu.info/oxauth/authorize?response_type=code&scope=openid&redirect_uri=https%3A%2F%2Fapache.gluu.info%2Fprotected%2Fcgi-bin%2FprintHeaders.cgi&nonce=t4aNwS7CfUrMqP34_MjVzSZYt0OP-ANiJz9Hf7bWR24&login_hint=admin%40ce.gluu.info&state=Tdo7kd1UTh7zHaCHMox7mpMv9M4&client_id=%40%21C7A3.9197.CAF5.4694%210001%21BF1E.91F9%210008%2115FB.595A
[Mon Jun 01 23:20:11.994013 2015] [auth_openidc:error] [pid 18808:tid 139647229323008] [client 192.168.177.1:54851] oidc_authorization_response_match_state: unable to restore state, referer: https://ce.gluu.info/oxauth/authorize?response_type=code&scope=openid&redirect_uri=https%3A%2F%2Fapache.gluu.info%2Fprotected%2Fcgi-bin%2FprintHeaders.cgi&nonce=t4aNwS7CfUrMqP34_MjVzSZYt0OP-ANiJz9Hf7bWR24&login_hint=admin%40ce.gluu.info&state=Tdo7kd1UTh7zHaCHMox7mpMv9M4&client_id=%40%21C7A3.9197.CAF5.4694%210001%21BF1E.91F9%210008%2115FB.595A

[nynymike]

I put my notes here if anyone is interested... http://gluu.co/mod_auth_oidc_notes

[zandbelt]

The default Discovery page does not leverage a cookie to store a previous selection and reuse that. I expect that noone will use the default Discovery page in production because of its look-and-feel so it is merely for testing. A custom Discovery page can be created as documented in: https://github.com/pingidentity/mod_auth_openidc/wiki#12-how-can-i-customize-the-idp-discovery-or-initial-login-page.

I will have to look in to IE 11's behaviour. It looks like it doesn't send the state cookie to mod_auth_openidc. If you have a browser trace (i.e. Fiddler) that would be convenient, otherwise I will have to find a Windows machine...

[zandbelt]

I tested with IE 11 (IE 10.9.9600.17801 Update versions: 11.0191) on Windows Server 2008 against seed22.gluu.org and Dynamic Client Registration plus login works OK. It looks like your IE 11 doesn't send the state cookie across; could that be a security setting in IE 11 (e.g. to not send it to hosts that don't have a valid SSL server cert)?

[zandbelt]

@nynymike do you still have this issue? if so, any browser trace that you could paste?

[nynymike]

Will let you know. Thanks for the link!

On 2015-06-23 16:00, Hans Zandbelt wrote:

@nynymike [1] do you still have this issue? if so, any browser trace
that you could paste?

Reply to this email directly or view it on GitHub [2].

Links:

[1] https://github.com/nynymike
[2]
#70 (comment)