I'm struggling with Keycloak for what seems a simple problem and, after reading a lot of stuff about the subject, nothing solved my problem yet.
The problem is that I call a url with fragment like http://hostname:8080/somewebui/#!builder/site.com:manager:manager/1.0.0/hostname=anotherhostname.
The fragment after the # allow me to pre-fill fields on the site so that the user has just to click on a button to save the data.
The site is protected by Keycloak.
If I'm already logged on the site and I call this URL, it work fine, the site opens and the requested fields are filled, it's perfect.
On the contrary, if I'm not yet logged on the site (most usual case), the login page managed by Keycloak is displayed asking to enter credentials, which is normal.
But after I successfully enter the credentials, Keycloak redirect me to http://hostname:8080/somewebui/, without the fragment.
My question is therefore simple, how can I said to Keycloak to keep the fragments after a login ?
Thank you in advance,
Seb
https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2
The endpoint URI MUST NOT include a fragment component.
So fragment in redirect URI can't be supported if the standard is implemented correctly.
Related
I have an ASP .Net MVC5 application using Azure AD Authentication. Whenever I enter URL, it takes me for authentication (if not done already) using a URL of this sort.
https://login.microsoftonline.com/[tenantID]/oauth2/v2.0/authorize?
There are 3 questions
Can I say its using OAuth2 ?
If someone enters a url for a page e.g. https://mydomain/Category/View/1, then it goes for auth (which is alright), but then post successful authentication, it should redirect me to the originally requested URL but currently its taking me to the root URL https://mydomain . But subsequent ones, work fine once authenticated.
Currently the auth happens every 1 hr I believe..how can I extend it to every 4 hrs ?
Will be helpful to see your suggestions.
Cheers.
According to your description of point 2, would you like to achieve that, visiting a url -> direct to login page -> redirect to that url? If so, I think this document can help you.
In my opinion, if I wanna a demo app or app just for simple test, just add all possible url to the redirect configuration form. If I need to do an formal app or I need to make it easy to maintain, I use the idea in the above document. I think the centeral thought is creating a specific place to control url redirecting, including judgment, and only need to add this specific url to the redirect configuration in azure portal. If you wanna a sample, may this document will help you.
To point 3, emmm perhaps you can search for some key words like 'azure ad authentication set token lifetime policy', I found several powershell scripts but I haven't tested. If you haven't got the result I will do some test on it next Monday.
Some websites like Facebook and Ask FM use #_=_ at the end of an URL to an external website. Why?
If two large websites are doing so, surely it must mean something?
The problem is after authenticating with Facebook. The base path becomes a hash which eventually breaks the navigation.
I think this is because of facebook passing the url with some hash key. Because with or without passing redirection url facebook passing this to avoid vulnerability of attacks.
From https://developers.facebook.com/blog/post/552/, change in Session Redirect Behavior:
This week, we started adding a fragment #= to the redirect_uri when this field is left blank. Please ensure that your app can handle this behavior.
A solution is simply removing the hash as stated here then everything seems back to normal:
Facebook Callback appends '#_=_' to Return URL
Let's say I have an application that's going to be accessed from completely different domains that all point at the same server*:
example.com, example.net, foobar.com, ...
I have a Devise based authentication system that's worked fine before. However, the goal is now to add HTTPS to the sign in system. The problem is, as it turns out, there is no way to host more than one HTTPS website on the same IP address**. To resolve this problem, I set up the login pages to always POST to https://secure.example.com. As far as I can tell, this is working fine. Devise seems to have no qualm with it. However, the tricky part is that the user now needs to be redirected to foobar.com, which also needs to understand that the user is logged in. I pass the site to return to in a hidden parameter in the login form, and the redirection works fine. I still have no way to inform foobar.com that the user is now logged in.
I've managed to set it up so that, upon being returned to foobar.com, it copies the user's session cookie for secure.example.com into a new cookie for foobar.com. This part is working fine. However, in the Rails console, the web requests for secure.example.com and foobar.com - with the same cookie sent for each - produce two completely different sessions and therefore, it's no wonder Devise acts like the user was never logged in to foobar.com
Does anyone know why this wouldn't work - why two identical web requests (only the domain of the request URI was different - I tried it in Firebug, too) would produce two completely different sessions in a Rails 3 app with different, yet consistent, session ids? More to the point, does anyone know how to MAKE this work?
* assume, for the purposes of this exercise, that this is unavoidable and the sites cannot be hosted all under different subdomains, and that the number of domains required is too great to get a separate IP address for each.
** unless they're subdomains and you have an *.example.com cert, but that's beside the point.
If you're already using Devise, I suggest you try using token authenticatable. You can generate a token for the user in question, redirect them with the token to sign in, and then quickly expire the token after they have signed in.
You could also try rolling your own OAuth provider with doorkeeper.
I have a web application that I am trying not to recompile since there is little documentation and the environment is a little sensitive.
With that in mind, all I am trying to do is hijack the authentication mechanism to redirect to one of a couple replacement websites. To that end, there is an authentication service and an authentication controller. The website redirects to /auth/login when the user comes unauthenticated.
In the views folder I have built an alternative /auth/login_new.gsp and from there can authenticate the user and get a redirection back to /auth/redirect.gsp at some frequency but not 100%. That redirect page takes a value from the DB and redirects the user to the correct follow on website. When I run authentication from /auth/login, the site ignores the redirect request to /auth/redirect.gsp.
I had set the show pages for all the different controllers to window.location.href="/auth/redirect.gsp" but I can't get it to go there 100%. I have also reset the layout/domain.gsp file to gut the other functionality of the site and script redirect as well. I was getting errors with duplicate redirect attempts, but now I just go to a dead/gutted homepage...
Any suggestions on how I can dodge the recompile?
Thanks
Leif
I'm using PrettyFaces 3.3.3. I have a requirement that if a user tries to view a page, but is not logged in, they are sent to the login page, and then redirected to the original page they wanted to view. Just wondering what would be the best approach for this.
You probably want a security framework here. The basic idea is that you'd want to intercept the requested URL in your security filter, save it into the user's session, then once authentication is complete (e.g. user has submitted the form with their credentials, or whatever mechanism you're using) you retrieve the saved URL from the user's session and perform a 302 Redirect to it.
This is not something PrettyFaces will help you with directly, except that you can use it to capture the URL more easily using PrettyContext.getCurrentInstance(request).getRequestURL();
There is an article about this here: http://ocpsoft.org/java/jsf-java/spring-security-what-happens-after-you-log-in/
Using OCPsoft Rewrite (core of PrettyFaces 4) you can do this programatically as well, and even do the authentication directly in your security rules or annotation config: https://github.com/ocpsoft/prettyfaces/blob/master/annotations/src/test/java/org/ocpsoft/prettyfaces/annotation/jaas/JaasRolesBean.java
This is an upcoming feature but is not yet complete - we would love feedback.