Custom URL parameters lost after OpenAM login redirection - redirect

I'm using OpenAM for authentication on my application. I access to my app using such URL:
http://my.company.com/appfolder/appservlet?lang=EN&user=test
On first access, OpenAM agent catches the URL and redirect my browser to the authentication page using this redirection URL:
...openam/UI/Login?goto=http%3A%2F%2Fmy.company.com%3A8080%2Fappfolder
After correct authentication, I'm finally redirected to the following URL:
http://my.company.com/appfolder
This is logic since this is the URL referenced in goto param. But it's not the same than original one: the servlet and custom params (lang and user) are missing.
Any idea how to configure my agent to make it keep servlet and params after redirection ?

take a look at this step of the tutorial "Add Authentication to a Website using OpenAM".
In section "Creating An Access Policy" -> "Wildcard matching" is your answer:
The wildcard * in policy URLs does not match '?'. As such if you
wish to allow GET parameters to be submitted then a second policy for
http://webserver.example.com/*?* is required.

Thanks for your answer. As mentionned in my previous comment, the adding of new policy does not resolve my issue. Actually, I'm not sure to understand how the policies can solve the issue since the goto parameter is generated by the J2EE agent, which acts before policies are applied (as far as I know... I'm maybe wrong).
Anyway, I could solve my problem by re-compiling the J2EE Agent: I've build a new agent.jar based on v3.0.3 available at forgerock. Then I replaced the AmFilterRequestContext.class by a new one, build on source available here:
http://www.docjar.com/html/api/com/sun/identity/agents/filter/AmFilterRequestContext.java.html
With this new agent, my goto is now correct, and redirection works well (and I don't have to define any policy).
The strange thing is that I don't understand why it works now ! I couldn't find any difference between java source mentionned above and uncompiled version of original class! I just added some System.out.println to get variables values and functions results, and built the jar. After restaring my jboss, the goto was correct. I'll try to understand why this finally work now when I've time.

Related

keycloak: using react user can login but when I try logout I get a message "Invalid parameter: redirect_uri"

I'm trying to use keycloak with a react app, this is my current client configuration...I did this inside the master realm
this is my keycloak config
export const keycloakConfig = {
"realm": "master",
"auth-server-url": "http://localhost:8180/",
"ssl-required": "external",
"resource": "demo",
"public-client": true,
"confidential-port": 0,
"clientId" : "demo",
"url" : "http://localhost:8180/"
};
I based my code on this repo
now...I can login without problems in my app, and the displayed url is this
http://localhost:8180/realms/master/protocol/openid-connect/auth?client_id=demo&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F&state=ba9daf04-ffdb-4ad3-b912-8be846f0684b&response_mode=fragment&response_type=code&scope=openid&nonce=558d71b7-2c66-44f8-9297-84694dc571a8
but when I try to logout I get a message
Invalid parameter: redirect_uri
the logout url is this
http://localhost:8180/realms/master/protocol/openid-connect/logout?redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F
I'm not sure if my client config is correct because this has several missing parameters in almost all tutorials that I've found
Do you know what could be the problem here?
thank you guys
From the Release Notes:
OpenID Connect Logout
Previous versions of Keycloak had supported automatic logout of the
user and redirecting to the application by opening logout endpoint URL
such as
http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri.
While that implementation was easy to use, it had potentially negative
impact on performance and security. The new version has better support
for logout based on the OpenID Connect RP-Initiated Logout
specification. The parameter redirect_uri is no longer supported;
also, in the new version, the user needs to confirm the logout. It is
possible to omit the confirmation and do automatic redirect to the
application when you include parameter post_logout_redirect_uri
together with the parameter id_token_hint with the ID Token used for
login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as
described above. Consider either removing the redirect_uri parameter
entirely or replacing it with the id_token_hint and
post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call
uses the backchannel variant of the logout endpoint and that one was
not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the
JavaScript adapter, you are affected as this adapter uses the variant
of the logout endpoint with the deprecated redirect_uri parameter. In
this case, you may need to upgrade to the latest version of the
JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version
as the older version of the adapter uses the deprecated redirect_uri
parameter. With the latest Node.js adapter, you are not affected as
long as you use the logout based on the /logout URL as described in
the documentation or in the Node.js adapter example. However, in the
case when your application directly uses the method
keycloak.logoutUrl, you can consider adding idTokenHint as the second
argument to this method. The possibility to add idTokenHint as second
argument was newly added in this version. The idTokenHint needs to be
a valid ID Token that was obtained during the login. Adding
idTokenHint is optional, but if you omit it, your users will need to
confirm the logout screen as described earlier. Also they will not be
redirected back to the application after logout.
There is a backwards compatibility option, which allows your
application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering
the following command:
bin/kc.[sh|bat]
--spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the
redirect_uri parameter. Note the confirmation screen will be needed if
the id_token_hint is omitted. Warning The backwards compatibility
switch will be removed in some future version - probably Keycloak 21.
You are encouraged to update your clients as soon as possible as
described above rather than rely on this switch.
I've got the same problem already for hours. The only way I found a workaround is manually sending the user to:
/realms//protocol/openid-connect/logout
I started using Keycloak 18.0.0 since a few days and I cannot find any other solution for this problem. I guess it's only happening to when using the newest version. Maybe we should read the documentation better.
For last Keycloack versions you have to redirect explicitly to
https://you server url/auth/realms/matrix/protocol/openid-connect/logout
This issue comes when the keycloak is upgraded to version 18. So we also need to upgrade Keycloak JS & keycloak-angular package.
https://www.npmjs.com/package/keycloak-js
https://www.npmjs.com/package/keycloak-angular
Rest everything will be similar

Github Action URL Checker failing, despite working link

I am using the urlchecker action on my Github Repository to check for broken urls.
However, my link which seems to work is giving an error when being checked by the respective urlchecker Github action.
I have tried using url-shortner, but that doesn't work?
What am I missing here?
I realised that one of the links didn't have a vaild SSL certificate and only had TSL certificates. Moereover, the Github URLChecker Action might be using Pythons requests.get(url) which seems to verify for SSL by default as mentioned here, therefore a compeletely working link without an SSL(maybe having a TLS) might fail the URL Check.
(This is speculation from my side as to how the url checker action works but the most likely scenario in this case )

Keycloak URL fragments do not disappear when logged in

Keycloak inserts session_state, state and code in url fragment params.. sometimes after successful login these remain on the url...
Or, when alternate routes are clicked in the app, these appear again.
Unnecessarily exposing the internals of keycloak params to users.
Is there some solution to not have these appear or delete them?
e.g. http://localhost:3000/home/#state=e625140e-c4f9-4500-858e-32c80e89f8a9&session_state=445229c3-d7eb-46e9-bfba-3339253dd17e&code=af0abde4-a60d-4f34-a101-8db5c76546b9.445229c3-d7eb-46e9-bfba-3339253dd17e.59915134-a59b-4ffb-878a-d02e7e84f2dd
Update:
with more tests narrowed down the issue to occur when
anything on the keycloak instance is touched. e.g. keycloak.token
any function call of keycloak is invoked... then after that these params get added and removed for every url route thereafter...
e.g. await keycloak.updateToken()
Keycloak Sever and js lib Version : 9.0.2
It is not a Keycloak issue. That's how used login flow works (maybe you need different flow, which will be more suitable for your use case). Your app code (used OIDC/OAuth library) should "clean" URL fragments. Cleaning can be: exchange code for the token (in this particular case), remove URL fragments, clean browser history, etc.

Facebook OAuth SSO Issue

I have a JavaEE Application. I am trying to implement OAuth.
But I am facing some strange issues:
As per the documentation to manually building the sign in web flow I have to provide a link like this https://www.facebook.com/dialog/oauth?client_id=1231298371123&display=popup&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fc%2Fportal%2Fauth%2Ffacebook_login%3F&scope=email,public_profile,user_birthday&response_type=code%20token which will open the dialog. But the dialog is not opening.
And when the SSO is successful FB is redirecting to the url given above but the problem is FB is appending the query strings like state, code, etc with #. Something like: http://localhost:8080/c/portal/auth/facebook_login?#state=ASDASDASDASD&access_token=EAANXZAlBTi........ Because for this I cannot get the parameters in Java.
Do any one came across this kind of issue.
Please help.
Not sure if I understood the question right but if you want to read the string after # you can use the following code
URI uri = new URI("http://test.com/#something=some");
String fragment = uri.getFragment();
fragment will be everything after #

Jenkins embeddable build status icon not shown

I want to use the Embeddable Build Status Plugin for Jenkins. I am using Cloudbees. I granted Job/ViewStatus permissions to the anonymous user. When I add the Markdown to the README.md no icon is shown. I tried both the protected and the unprotected link.
# protected
[![Build Status](https://johnjohndoe.ci.cloudbees.com/job/TypedPreferences/badge/icon)](https://johnjohndoe.ci.cloudbees.com/job/TypedPreferences/)
# unprotected
[![Build Status](https://johnjohndoe.ci.cloudbees.com/buildStatus/icon?job=TypedPreferences)](https://johnjohndoe.ci.cloudbees.com/job/TypedPreferences/)
By default DEV#cloud Jenkins instances are not visible, at all, to anonymous users. If you have configured role-based security and want anonymous users to have the selected roles, configure your system and check the box Enable read-only access for anonymous users.
Well, the question has been asked some time ago, but for others reaching it here, having the problem, that the image is still not shown within the Readme.md on GitHub/GitHub-Enterprise after performing the above mentioned configuration:
Make sure that both services are using the same protocol. In my case, we had GitHub-Enterprise running under HTTPS and Jenkins was running on HTTP.
The badge will not be shown in this case because of the possible security breach introduced by mixed content. You will find an appropriate error message in the console output of your browser (i.e. F12 in Chrome):
Mixed Content: The page at 'https://.../README.md' was loaded over HTTPS,
but requested an insecure image 'http://.../job/master/badge/icon'.
This request has been blocked; the content must be served over HTTPS.
It's of course quite obvious but something that can also be easily missed when searching on the wrong track.
I had an issue with space in the project name, so do not forget to replace spaces with %20
example:
[![Build Status](../Long%20Project%20Name/...)](.../Long%20Project%20Name/...)