I've implemented IdentityServer3 in my application and it has been working really good. However recently I came across some behaviour I can't quite figure out so I was hoping someone could tell me what I'm either doing wrong or how I should be doing the following:
I have a ASP.NET MVC application that uses IdentityServer for authentication. The user authenticates and opens a specific page within the application. He moves away from his PC, comes back a little later and clicks another link within the application (e.g. controller/action/38). The application then redirects the user to:
http://localhost/MyIdentityServer/identity/connect/authorize?client_id=myapp&redirect_uri=http://localhost/MyApp/controller/action/38&response_mode=form_post&response_type=id_token&scope=openid+profile+roles etc.
Since only the root url of the app (http://localhost/MyApp) is registered as a RedirectUrl in IdentityServer it shows the following message:
The client application is not known or is not authorized.
Rightfully so, since the controller + action aren't valid RedirectUrls. However, I cannot image that I'd have to add all the controllers and actions to the RedirectUrl property, especially since they take data-related parameters. Surely I must be doing something wrong but what?
You're modifying the redirecturi provided to idsrv on each request to idsrv:
remove this line:
notification.ProtocolMessage.RedirectUri = something
Related
I would think this question has been asked 1,000 times, but I actually haven't been able to find it anywhere (at least not for Laravel 5.2). I'm trying to implement user admin functionality through a RESTful API (I'm not talking about OAuth2, I already got that up and running). Basically, I need all the stuff Route::auth() does through a web interface, but I want to do it without the web interface and without the redirects that Route::auth() returns.
It seems like I can send POST requests to the underlying routes of Route::auth() (register, login, logout, password...) and it properly validates the POST and acts, but there's no useful data returned and it always redirects to / as the response. For example, if I register a new user, it creates the account correctly and redirects to /, but there's no "success" message. If I try to register a new user with an email address that's already in the user table, it catches that the user already exists and does not create a duplicate, but the response doesn't indicate that. It still just redirects to / with no other response. I don't get any sort of error code or message to tell my app that the user already exists.
Before anyone links to jwt-auth, I've looked at it already and I don't think it does what I'm talking about here.
Is there something I'm missing or do I need to re-write all of these routes and auth methods for proper API functionality?
So, I've setup an auth system using djoser and rest-social-auth ( https://github.com/st4lk/django-rest-social-auth )
but it seems it requires the client to open a pop-up or modal to login with facebook, which our frontend dev says is a bad idea, we should use server-side redirects instead.
So - assuming this is sensible - how do I go about the serverside setup to skip the facebook modal on client side? I'm happy to swap out the current social auth lib with something else if it makes things easier.
FWIW - we are using angular on frontend, but are also planning on other frontends in the future
The client side authorization with the JavaScript SDK is the easiest one, and it is perfectly safe. It´s also the best one for the user, because you do not need to redirect to a login page. Not sure why your frontend dev says it´s a bad idea, it´s actually the best and recommended way. The popup is ok in that case, because it is initiated by the user. Here´s an example: http://www.devils-heaven.com/facebook-javascript-sdk-login/
After authorization, you can send the Access Token to the server, in case you need it there. Make sure you read this though, and use appsecret_proof: https://developers.facebook.com/docs/graph-api/securing-requests
You can easily put the code in an Angular service, for example.
Let me preface this by admitting that this is my first webapp and first experience with JSF, so I've probably made some poor design decisions.
Here's what I'm trying to do:
I have a webapp using JSF 2.0, which is accessible through a Facebook canvas. This webapp allows a user to view/manipulate data from a database of sensor readings. On the very first time the Facebook user accesses my app, I ask the user to enter login credentials for the database, then send the user to the home page. Thereafter, the user should always go straight to the home page, since I associate the user's FB id with the database user profile.
Current implementation:
I have the Facebook canvas URL going to a servlet. This servlet checks the signed_request parameter passed by Facebook to get the user ID, and then looks in the database to see if the user has already completed the provisioning process. If the user has done so, he is redirected to the application home page.
The problem:
Most of my logic to do these checks currently exists within a managed bean (session-scoped). To use the bean within the servlet, I'm manually instantiating the bean and adding it to the session, since the JSF framework hasn't had a chance to create it yet. As my system is getting more complicated, this is causing problems due to dependencies between the various beans. Also, it seems like a generally bad approach to the problem.
Solutions? From my web searching, it sounds like there might be several ways to do this. One way would be to set the canvas to a JSF landing page, where a managed bean would grab the signed_request parameter and validate that the user has completed the provisioning step. From there, the bean would forward to the proper page. Another possibility might be to have an eager bean that does the same thing, but this seems "wrong".
What's the best way to resolve this and adhere to "proper" JSF paradigms?
Thanks in advance!
There are a number of different ways that this can be handled. The JSF landing page is one idea and the eager bean are some ways that this can be handled.
If you ignore the fact that you are integrating with Facebook then ultimately you are trying to solve an authentication and authorization problem. Facebook is handling your authentication, and telling your web application what the identity of a user is, and it is your web app's job to remember that person's identity throughout the session, and authorize this person to visit the requested page.
I have implemented it before where I had all of my managed beans extend a BaseBean class that on creation and initialization checked for the existence of a specific SessionScoped bean that contained the user identitification information. If this bean did not exist or was not authorized to access this bean then I would redirect. The problem with this approach was that it authorized only the use of managed beans, and not pages.
Another approach I had was to utilize a servlet filter that would essentially check every page request and look for the session scoped bean that contained the currently authenticated user. If this wasn't found then I would look for the specific request parameters and authenticate and create the session bean, and if that didn't exist would redirect to an Unauthorized page.
This approach worked well until I realized that Authentication and Authorization of Java web applications is a well understood and near universal problem. After a little bit of looking and research I discovered that security frameworks like Spring Security 3 can indeed be integrated into JSF and handle nearly all of the complexity of complex authentication and authorization. You could very easily integrate a custom Facebook authentication handler for Spring Security and control access by user role to the individual page level, all from XML configuration. It is highly worth looking into if you have the time to learn something new.
I'm retrofitting my application with GWT History support, and I've stumbled on a case where I'm not quite sure what to do. The answer to this question doesn't necessarily have to be GWT-related.
GWT's History support functions by passing around hash tags (i.e. index.html#token). Security restrictions require users be logged in prior to actually being able to access index.html, so they get sent over to a login page, retaining the token (login.html#token). So far, so good. Now the user becomes authenticated and Spring sends them over to index.html (the default target) and eliminates the #token part of the URL.
How can I force Spring Security to maintain the token and send my newly authenticated user to the page they requested (index.html#token)? Since I've already got Spring Security authentication working, I'd prefer to not restructure the way my app handles logins.
After a great deal of digging, I found my answer on Spring's Jira. As Colin Alworth stated, that token isn't actually part of the request, so Spring Security never sees it server-side, and thus can't use it to determine the final URL. So the approach I used was to append the hash (client-side) to j_spring_security_check, making it j_spring_security_check#token. Now the token gets passed along just fine, allowing me to have a well-secured app with working tokens.
Thanks for your help Colin, your answer got me thinking in the right direction.
The server doesn't get to see this token as part of the GET/POST request as you've noted, it is only seen by the browser. Best fix that I've seen for this in the past is for the login page to take note of the current window.location.hash, and pass that along, either along with the login form (assuming a redirect will take place that keeps the hash around), or to the server as a login param so it can redirect properly.
Here's what happens, it might help you solve the problem:
sending unauthenticated users from index.html to login.html is most
likely implemented as an HTTP 3xx redirect, and that's why the
browser keeps the hash fragment (#token).
Once they login, spring sends them from login.html to index.html not
via 3xx redirect so the browser doesn't keep the token.
One solution would be to inject the token into index.html, and pick it up with GWT. Another one is to make login.html -> index.html a 3xx redirect (if spring allows that).
I have a GWT app to deploy to Tomcat on a Windows server, with the following requirements:
1- The app should work fully, whether the user is in the Windows domain or not;
2- If the user happens to be in the domain, the app should be able to identify the user in some manner. Presumably, this should be via getThreadLocalRequest().getRemoteUser(), but any other alternative is fine...
3- If the user happens to be in the domain, the app should be able to access the MS Exchange server in that domain, without requiring the user to enter their password.
I've scoured the web high and low for this, but unfortunately, it seems there's no way to get authentication without forcing authentication. There are many examples of exclusions for, say, a login form or other "public" resources, but that won't work for us, since all the resources in a GWT app are packed into the same "page".
Maybe it's my limited understanding that's making me fail in some basic way, but I've tried to look at JCIFS, Jespa, Waffle and SPNEGO, and I just can't seem to get working the way I want to...
Any help would be greatly appreciated.
Cheers,
J.
How about putting a Javascript on your front page and have a Kerberos/SPNEGO protected page. The javascript will attempt to request a protected page, if the user is on the domain you will get the correct result from the page otherwise you will get 401 access denied. In the former case you can redirect your browser to exchange page, or have another AJAX call to retrieve things from exchange server in the later case you either show a log-in form or a generic anonymous page.
What about using JNI to call the Win32Api function LogonUser?
By doing impersonation at the thread level you will have the NTLM token added to the current thread and you would be able to call exchange with no issues