I’m enabling OpenID Connect Authenticator to use Office365/AzureAD login.
So far, I can pass the Office365 login but when calling back the Wiki using its callback (/xwiki/oidc/authenticator/callback?..):
org.xwiki.resource.ResourceReferenceHandlerException: Failed to handle http servlet request
org.xwiki.contrib.oidc.provider.internal.OIDCResourceReferenceHandler.handle(OIDCResourceReferenceHandler.java:110)
org.xwiki.resource.internal.DefaultResourceReferenceHandlerChain.handleNext(DefaultResourceReferenceHandlerChain.java:79)
org.xwiki.resource.internal.AbstractResourceReferenceHandlerManager.handle(AbstractResourceReferenceHandlerManager.java:82)
org.xwiki.resource.servlet.ResourceReferenceHandlerServlet.handleResourceReference(ResourceReferenceHandlerServlet.java:159)
org.xwiki.resource.servlet.ResourceReferenceHandlerServlet.service(ResourceReferenceHandlerServlet.java:87)
javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
org.xwiki.container.servlet.filters.internal.SetHTTPHeaderFilter.doFilter(SetHTTPHeaderFilter.java:63)
org.xwiki.resource.servlet.RoutingFilter.doFilter(RoutingFilter.java:147)
Root Cause
org.xwiki.contrib.oidc.provider.internal.OIDCException: Failed to get access token:invalid_client
org.xwiki.contrib.oidc.auth.internal.endpoint.CallbackOIDCEndpoint.handle(CallbackOIDCEndpoint.java:134)
org.xwiki.contrib.oidc.provider.internal.OIDCResourceReferenceHandler.handle(OIDCResourceReferenceHandler.java:134)
org.xwiki.contrib.oidc.provider.internal.OIDCResourceReferenceHandler.handle(OIDCResourceReferenceHandler.java:108)
org.xwiki.resource.internal.DefaultResourceReferenceHandlerChain.handleNext(DefaultResourceReferenceHandlerChain.java:79)
org.xwiki.resource.internal.AbstractResourceReferenceHandlerManager.handle(AbstractResourceReferenceHandlerManager.java:82)
org.xwiki.resource.servlet.ResourceReferenceHandlerServlet.handleResourceReference(ResourceReferenceHandlerServlet.java:159)
org.xwiki.resource.servlet.ResourceReferenceHandlerServlet.service(ResourceReferenceHandlerServlet.java:87)
javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
org.xwiki.container.servlet.filters.internal.SetHTTPHeaderFilter.doFilter(SetHTTPHeaderFilter.java:63)
org.xwiki.resource.servlet.RoutingFilter.doFilter(RoutingFilter.java:147)
Note The full stack trace of the root cause is available in the server logs.
Yes that’s Loading.... It means the provider you are using only allows clients you explicitly registered on it to authenticate, unfortunately this OpenID Connect extension is not implemented yet in the authenticator.
That’s sad. As you marked the change as easy and as it’s been opened since 2017, and as you have several threads here about this matter, idea plan to fix this ?
Also, I’d love testing this but I struggle accessing the License menu whatever admin or superadmin I use
And both assigned groups/users have programming permissions enabled
“Only the administrators with programming rights are allowed to manage the licenses.”
Hello @faichelbaum. You should know that you’re on xwiki.org and this forum is the community support for all free extensions from extensions.xwiki.org. You seem to be referring to a “Pro” extension, which I think means an paying extension provided by XWiki SAS on store.xwiki.com. XWiki SAS is providing some professional support for what it sells. Please contact them or check store.xwiki.com.
But I have a question. When user login first time account is created but only with First Name and Last name filled. Is there any option to fill other data like email?
I have try with:
By default you get all the standard OIDC fields filled in the XWiki user. In your JSON you only have the first and last name. You can see Final: OpenID Connect Core 1.0 incorporating errata set 2 for the list of standard OIDC claims.
If you look at the User Profile administration as I suggested you will notice that there is a field named “blogfeed” so that’s what you should use. You also have a link to the user class where you can see all the existing fields id and display name and add new ones if needed.
response ({
"error": {
"code": "BadRequest",
"message": "The MIME type 'text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2' requires a '/' character between type and subtype, such as 'text/plain'.",
"innerError": {
"request-id": "b0aaaeb0-1aaa-4bc2-9aaa-511aaaaae4ae",
"date": "2020-03-19T17:17:13"
}
}
}
)
As far as I understand the request does not send any Accept right now so no idea where what you get is coming from. Also the authenticator is using oauth2-oidc-sdk library for this so this discussion should go there instead since it’s not the authenticator job to decide this IMO.
What is indicated on stackoverflow is that POSTman set this Accept by default but that’s not what is used here. Maybe you have some proxy which does that or maybe a proxy in front of https://graph.microsoft.com/v1.0/me.
It’s not really the question, of course it’s easy to set a custom Accept but it would be more interresting to:
understand why you end up with that Accept
understand why it’s not set explicitly in oauth2-oidc-sdk, this suggest the OIDC specification does not indicate any Accept`