OIDC without discovery url

[Bjarne]

Hi All,

I'm attempting to connect to an OpenId Connect service (WSO2 IS) which does not provide a Discovery URI service. 
As far as I can see the Pac4J OidcConfiguration only has the setDiscoveryURI() as method, but does not allow the individual endpoints to be configured manually.

What would be the best way to inform Pac4j of the correct endpoints?

Thanks in advnace!

/Richard

[Jérôme LELEU]

Hi,

Yes, we currently only support OpenID Connect provider with discovery URL.

Though it's the second time I get this kind of question, so I just opened: https://github.com/pac4j/pac4j/issues/693 and submitted a PR: https://github.com/pac4j/pac4j/pull/694

With this change, you'll be able to set a OIDCProviderMetadata in the OidcConfiguration (instead of retrieving the metadata from the discovery URL).

Can you test it (you'll need to locally build the sources with the PR and use the 1.9.3-SNAPSHOT version)?

The resource retriever is also used by the IdTokenValidator, so you may need to define your own.

Just let me know how it goes. 

Thanks.

Best regards,

Jérôme

--
You received this message because you are subscribed to the Google Groups "pac4j-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard]

Thank you Jérôme for your quick reply.

I'll give your change a go.

/Richard

Op woensdag 28 september 2016 14:02:04 UTC+2 schreef Jérôme LELEU:

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users...@googlegroups.com.

[Richard]

Using the provider data from https://accounts.google.com/.well-known/openid-configuration together with the 1.9.3-SNAPSHOT build works like a charm.

I've used the play-pac4j-java-demo to test it. I've changed the  OpenId Connect code to:

....

OIDCProviderMetadata meta = null;
try
{
   Issuer issuer = new Issuer("https://accounts.google.com");
   List<SubjectType> subjectTypes =Arrays.asList(SubjectType.PUBLIC);
   URI jwkSetURI = new URI("https://www.googleapis.com/oauth2/v3/certs");
   List<ResponseType> responseTypes = Arrays
         .asList(ResponseType.parse("code"), ResponseType.parse("token"), ResponseType.parse("id_token"),
               ResponseType.parse("code token"), ResponseType.parse("code id_token"), ResponseType.parse("token id_token"),
               ResponseType.parse("code token id_token"), ResponseType.parse("none"));
   meta = new OIDCProviderMetadata(issuer, subjectTypes, jwkSetURI);
   meta.setAuthorizationEndpointURI(new URI("https://accounts.google.com/o/oauth2/v2/auth"));
   meta.setTokenEndpointURI(new URI("https://www.googleapis.com/oauth2/v4/token"));
   meta.setUserInfoEndpointURI(new URI("https://www.googleapis.com/oauth2/v3/userinfo"));
   meta.setIDTokenJWSAlgs(Arrays.asList(JWSAlgorithm.RS256));
   meta.setResponseTypes(responseTypes);
   meta.setScopes(Scope.parse(Arrays.asList("openid", "email", "profile")));
   meta.setTokenEndpointAuthMethods(Arrays.asList(ClientAuthenticationMethod.parse("client_secret_post"),
         ClientAuthenticationMethod.parse("client_secret_basic")));
   meta.setClaims(Arrays.asList("aud", "email", "email_verified", "exp", "family_name", "given_name", "iat", "iss", "locale", "name",
         "picture", "sub"));
   meta.setCodeChallengeMethods(Arrays.asList(CodeChallengeMethod.PLAIN, CodeChallengeMethod.S256));
}
catch (URISyntaxException e)
{
   e.printStackTrace();
}
catch (ParseException e)
{
   e.printStackTrace();
}

oidcConfiguration.setProviderMetadata(meta);

I've had no issues with the IdTokenValidator so far, but am not quite sure where that kicks in.

Hope this helps. I'll now try to configure it correctly for my WSO2 server.

Thanks again for your quick help.

/Richard

Op woensdag 28 september 2016 14:17:24 UTC+2 schreef Richard:

[Jérôme LELEU]

Hi,

Excellent! Keep us posted for your test with WSO2.

Thanks.

Best regards,

Jérôme

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.

[Richard]

Good morning Jérôme,

For now I'm putting WSO2 into the fridge. Configuring it correctly for OIDC is a real pain.

I'll be attempting to connect to KeyCloak instead. It does provide discovery.

Thanks again for your help so far!

When I've got the spare time to investigate with WSO2 I'll report back to you with the progress.

/Richard

Op woensdag 28 september 2016 15:59:41 UTC+2 schreef Jérôme LELEU:

[Jérôme LELEU]

Hi,

OK. I will merge the PR.

Keep us posted about your tests with Keycloak. We have several manual tests for OpenID Connect, but nothing for Keycloack yet: https://github.com/pac4j/pac4j/tree/master/pac4j-oidc/src/test/java/org/pac4j/oidc/run

Thanks.

Best regards,

Jérôme

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.

[Richard van Duijn]

Hi Jérôme,

I've got keycloak with pac4j-oidc part working. The configuration works as expected and using the discoveryURL is perfect.

On the other side i've created an angular application (with play as the rest-api provider) which i've protected using the keycloak javascript adapter (https://keycloak.gitbooks.io/securing-client-applications-guide/content/topics/oidc/javascript-adapter.html). This works as well and all ajax requests to my play backend contain a keycloak token header as described in the keycloak docs.

My question now is how to bind both frontend and backend together so the user does not have to login twice and both my frontend as my rest api's are protected. 

My guess is that I have to get the keycloak token from the ajax request header and provide it to the session OIDCProfile to allow it to check it's validity with keycloak.

Is this in your opinion a valid approach? Is it correct to assume we can use the token from the request header to authenticate the user via pac4j?

Many thanks for any pointers/help!

/Richard

Op do 29 sep. 2016 om 10:27 schreef Jérôme LELEU <lel...@gmail.com>:

[Richard van Duijn]

I forgot to mention.. This is the example I'm following, except that I'm not using akka http, but play with pac4j. 

http://bandrzejczak.com/blog/2015/12/06/sso-for-your-single-page-application-part-2-slash-2-akka-http/

/Richard

Op vr 7 okt. 2016 om 13:56 schreef Richard van Duijn <rjvd...@gmail.com>:

[Jérôme LELEU]

Hi,

So you have an access token sent as a header to your Play REST API.

The big question is how to validate the access token: you should call the userinfo endpoint to check it (http://stackoverflow.com/questions/38893059/keycloak-validate-access-token-and-get-keycloak-id).

Use the HeaderClient and create a specific UserInfoOidcAuthenticator which checks the access token on the userinfo endpoint: this would be an interesting contribution to the pac4j project.

Thanks.

Best regards,

Jérôme

/Richard

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.

[Rakesh Sarangi]

Hi,

I think this is be something I would be interested to do, as I am using pac4j no my current project and needed this feature. Can I just go ahead and create an issue in github and start working on it?

[Jérôme LELEU]

Yes. Sure. Go ahead...

You received this message because you are subscribed to the Google Groups "Pac4j users mailing list" group.