I'm attempting to secure an instance of GraphDB with Keycloak via OpenID. I've created a realm, a client and some users in Keycloak.
I then configured GraphDB based on the documentation. Now, when I click on the "Sign in with OpenID" button on GraphDB's login screen, it keeps me returning to the GraphDB login screen. I noticed an error in Keycloak's log saying:
KC-SERVICES0093: Invalid parameter value for: scope
[org.keycloak.events] (default task-1) type=LOGIN_ERROR, realmId=kodi, clientId=graphdb, userId=null, ipAddress=127.0.0.1, error=invalid_request, response_type=code, redirect_uri=http://localhost:7200/, response_mode=query
I checked the requests made in browser and it seems the following authentication request is the culprit:
http://localhost:8080/auth/realms/kodi/protocol/openid-connect/auth?response_type=code&scope=openid%20%20offline_access&client_id=graphdb&redirect_uri=http://localhost:7200/&&state=530bc478e086b3e6b4474c35b7649c34faf0e0ae1a36f4a36ba3eb2c&code_challenge=W4IA_YvcdXVYJbgApldqdoHePBXZxzToSaPdfgsxTYM&code_challenge_method=S256
I tested it in Postman and the problems seems to be that there are two spaces between the openid and offline_access scope query parameter values. As per documentation, scopes are supposed to be separated by a space, but apparently the problem is that there are two in the GraphDB request. If I manually remove one of the encoded spaces and rerun the request in Postman, it finishes without errors (resulting in the Keycloak login screen).
I'm not sure whether this is a Keycloak (be able to handle multiple spaces in scope params) or GraphDB (do not use two spaces to separate scope params) issue. Also, I couldn't find any configuration parameters to influence this. Any ideas how to resolve/work around this issue? Thanks
Update:
I already have a satisfactory answer from Pavel below, but just for future reference, the versions I tried were:
GraphDB 9.5.0
Keycloak 12.0.1
We are aware of the space issue with GraphDB and it will be addressed in a future version. It appears that some OpenID providers are more forgiving with the extra space than others. Unfortunately there is no known workaround at the moment.
Related
We’re trying to implement a Wopi Host following the protocol to integrate with OWA, as documented in here, and we’re having some issues with some points:
We have implemented a simple host that is only capable of viewing files, that is, it implements the CheckFileInfo and GetFile views. In a test environment, the flow is working and we’re able to view the files in OWA. The point is, when executing the Wopi Validator (the web and the docker version), we’re having an error in the GetFile operation because the validator is trying to access the endpoint with two // at the end:
host/wopi/files/file_id//contents
Is this a known issue that is happening only in the validator? Why are the two ‘/’ being appended to the end of the WopiSrc? How can we address this issue?
We have read some posts here stating that the editing is required in order to officially validate our OWA integration with Microsoft. Is this true? Isn’t the CheckFileInfo and GetFile views the only ones necessary to implement a simple Wopi host capable only of viewing files? We’re just passing the required information in the response of the CheckFileInfo operation. We’re not using FileUrl or any other parameter but the required ones. As far as I can see, these two views are the only one required for viewing files with OWA, such as stated here
Additionally, we’re having an issue in the first part of the flow, when the browser sends a request to OWA and passes the token and the WopiSrc. We were only able to make the flow work passing the token in the query string via the GET method. If we put it under a JSON with a POST method, the OWA simply ignores it and does not make an attempt to call the Wopi Host at all, via the WopiSrc. Could someone enlighten us a bit on this matter to figure out what may be happening?
Furthermore, we’re stuck in some point of token validation. The docs are crystal clear when they say that the token is generated by the host, and that it should be unique for a single user/file combination. We have done that. The problem is, how are we supposed to know what is the user that is trying to access a resource, when the request comes from OWA? For example, when the OWA calls the host in the CheckFileInfo and GetFile views, it passes us the token. But how could we know the user information as well? Since the token is for a single file (which we have in the address of the endpoint being accessed) and for a single user, how can we validate the user at this point? We have not found any header or placeholder value that could be used to extract this information when receiving a request from OWA, and we’re a bit lost here. We’ve thought about appending the user information to the token, and then extracting it back, but for what I could see, doing that I’m only ensuring that the token has not been modified between requests. Does anyone have any idea?
Regarding the validation with Microsfot demands the edit functionality.
For the POST situation, the submission must be made as a "form" not as JSON.
The token validation is completely open, you must choose the way you think would be the best approach. JWT is a good alternative in this case.
I'm using Twiki and the SsoLoginContrib extension with Keycloak to set up SSO. The LocalSite.cfg settings require $TWiki::cfg{SsoLoginContrib}{AuthTokenName} but I don't know what that setting should be when using Keycloak. How do I find the AuthTokenName in Keycloak?
I've tried 'AUTH_SESSION_ID', 'KEYCLOAK_IDENTITY' and 'KEYCLOAK_SESSION' because they were set in the cookie after successful authentication with a Keycloak user.
$TWiki::cfg{SsoLoginContrib}{AuthTokenName} = 'KEYCLOAK_IDENTITY';
I would expect the authentication to succeed and redirect to the Twiki/bin/view/Main page but there is no redirect, only the Keycloak realms//account page for the authenticated user.
I tried to reach out for help and use the resources available but I get "please format your question properly."
I used the 'wizard' provided by stackoverflow and entered the information.
I searched the web using multiple search engines.
I really had hoped the community was mature and friendly enough to help but my expectations are obviously too high.
The times have changed, the internet is now full of arrogant brats that have grudges against the world because they were bullied for being nerds. I understand that.
I give up.
My question is how I can access the driver's history using the Uber's API? What I have tried is including the partners.trips scope and tried multiple variations such as scope=partners.trips, partners.trips.content, trips. All have given me an invalid scope error when I try to authenticate.
I have noticed that I do not see partners.trips as an available option in my developer dashboard page (screenshot of dev dashboard). As of now, I see 2 possible problems that I could be having, but I could not find a solution from the documentation or FAQ.
My formatting or syntax is incorrect when I add scope=partners.trips to my authorization step
I don't have access to add partners.trips in my default scope and don't have a way to request it from Uber
"Access to the Driver API is currently limited. If you are interested in using this API, you can apply for access on the Drivers Product Page." - https://developer.uber.com/docs/drivers/introduction
I'm facing an issue in AEM6.1 were the users have an invalid login-token (due to having an expired session). They make a request to AEM author which then has an error because they are basically an anonymous user attempting to view a page. The access problem results in a 404. The ACS error page tries to handle it, but the error page like everything else on author is not readable to an anonymous user. So it has a Java exception, and the user is left with a white screen of death
The login-token cookies in the browser have no expiration. They appear to be configured to stick around until the session is closed by the users. I would like to set expiration on the login-token cookies.
I've research around but do not see how this is done. The aemstuff site http://www.aemstuff.com/#article964 points to "Apache Jackrabbit Oak TokenConfiguration" But this was already set to 43200000, and further changes do not effect the login cookie expiration as far as I can see.
My question for SO is; is there a way to set the login-token expiration on the cookie? It seems like a bug with "Apache Jackrabbit Oak TokenConfiguration" or is it?
Create Apache Jackrabbit Oak TokenConfiguration as a config node.
In case others face similar problems, here some of the things I learned about this
login-token expiration can be configured as suggested by disha. It is used on the backend only. I think its very typical for browser session cookies to not have an the expiry set.
The WSOD issue experienced may have been helped by adjusting this session timeout slightly less than the IDP timeout
I think it's very important to use Java 8 with AEM6.1 and perhaps other versions as well. When we upgraded from AEM6, Java 7 remained our running version. Possibly the SAML SSO uses Java 8 things. After going to Java 8, users never had the WSOD again.
Post LinkedIn changes (around May 2015) have disabled our use of the share feature, via API call using the URL http://api.linkedin.com/v1/people/~/shares?format=json. We are now receiving a "403 authorization failed".
Steps taken to rehabilitate our share function:
Confirmed that ClientId & Client Secret keys are still the same as being used in our app
The Default Application Permissions have been confirmed, w_share is selected...which used to be rw_share (no longer available). Other selections made are r_basicprofile, r_emailaddress, & rw_company_admin...which are seemingly not related.
Authorized Redirect URLs are still applied for the domain we are using our application under.
Content type has been set to "application/xml", as suggested by other postings.
We have tried for months...hoping that any post changes to LinkedIn would have resolved our problem, yet nothing we have researched has helped. We figure that this might be a glitch from the permission modification update done by LinkedIn...since our code has never change, yet has worked for 2+ years prior to the May 2015 changes.
We would appreciate any insight as to what is going on here....as we are continuing to have this problem.
I found the problem, it was because the security of Linkedin changed. We had to had to alter the statement:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
to this:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;
If you are relying on the "default application permissions", you may also want to double check that your OAuth code is not still requesting the old (no longer available) member permissions (e.g. rw_nus) via the ?scope= URL parameter, which will trump the "default application permissions" settings you've defined in your LinkedIn app's config.
Otherwise, the w_share permission should still be providing you the ability to post a share to LinkedIn.