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
Related
I'm working in creating a FORM (kind of survey) to get user input, any user who visited the website can provide me information. This would means, the API is actually public accessible to anyone without any token or session (basically nothing)
I want to prevent people from getting my endpoint and create thousand/millions of requests (SPAM) to flood my service and database. I've tried to look over Stackoverflow and some post in medium, it's interesting that I don't find much about this.
Some said:
bundle my website as an hybrid app, supply accessToken to only "trusted device" for firing my api (but this is a pure webapp)
creating custom header and identify the header from my web server (hmm..?)
use CAPTCHA (this will only stop people spamming via the GUI, but spamming via script still possible)
Is this simply no better way to secure, since it's public?
Any thoughts to share?
have you read about Request Queue?
it might help you solve the issue
source 1
source 2
I'm a bit confused about the making of a login service: I've seen plenty of tutorials, but still can't manage how to make a simple login service.
I don't know what tools I need to remember the navigation, and how to use them.
I could use:
public interface LoginServiceAsync {
boolean isAuthenticated(AsyncCallback<UserDTO> callback);
UserDTO authenticate(String email, String password, AsyncCallback<UserDTO> callback);
void logout(AsyncCallback<UserDTO> callback);
}
But where do I manage Cookies?
Pro Tip: if you don't fully understand how authentication should work, don't try to do it yourself.
IMO, the best way to do authentication is to just redirect to a login form and thus assume that when your app is loaded the user is authenticated (then you can use a JSP for example to pass user-specific values to your GWT app; see the guice-rf-activity archetype for an example). If your app has to be accessible to anonymous users, login would still just redirect to the login page. For a real-life example, have a look at how Google Groups behaves.
That way, you can delegate authentication to either some library that knows how to do it (e.g. Spring Security), or to some tool (e.g. standard servlets authentication, AppEngine-specific authentication)
GWT is just a tool that converts Java code into HTML and JavaScript. There is nothing special about authenticating users in GWT.
One option is to remember that a user is authenticated in a session, and then check the session every time a client makes an RPC call. The implementation depends on your web server. Google your web server and "sessions", and you will find plenty of details on how to do it.
I have also the same problem trying to find a login service. Finally we are using CAS Single Sign Out because we are working with Tomcat. In this case, users are directly logged in Tomcat server and not in GWT. Each user is configured to allow open a URL (GWT application) or not. For example, if the GWT application is hosted in htpp://myhost/GWTapp, it is possible to configure if a user can access to "/GWTapp" or not.
For me, the best benefit, it's that doesn't need to change a lot the GWT application with calls to server and so on. There is a GWT CAS client that makes all for you.
Can anyone think of a neat solution for this; we operate an website service and sell to large organisations. Rather than have a logon for everyone, we'd like to be able to provide a direct link to our website from the organisation's Intranet page. We'd then like to check the referrer and if it's in our listed of 'trusted referrers', i.e. the intranet url, then we grant logon without asking for credentials.
I'm aware you can do $_SERVER['HTTP_REFERER']; to get the referrer, but I'm also aware that can be spoofed. Can anyone think of how we could achieve what we want, but while also guaranteeing it won't be hackable?
Thanks in advance
It's not exectly what you want, but to make logging on easier and ensure you don't need to store all the passwords you could use, for example, OpenID.
I think that there is no perfect and safe solution for this.
One solution would be to append tokens to the urls. It will work and it will be save, but anyone who knows the link (including token) will be able to login as that organization
Another solution would be to check the source ip. This can be done in different ways *apache, load balancer, app, etc).
Also a combination of token + ip could work (this token for that organization but only if the request comes from allowed_ips for that organization)
A more elegant solution (which I implemented for several big companies) would be to integrate you website login with the active record domain login. It is possible to use the current user window login as login into a website, using domain authorization. If a user is logged in into a domain, when enters your site will automatically login to the website.
This solution is much more easy to implement than it sounds. But, requires Active directory and workstation that connects to a domain to be in the company (this shouldn't be a problem, most of corporations are using windows on workstations and active directory for domain controller). Also is working best on IE only (direct login to the website). On other browsers the domain login popup will appear and user will have to enter again the domain password.
Also, I am pretty sure that can be made to work on linux environments, but I have no idea how.
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'm developing a small CMS in PHP and we're putting on social integration.
The content is changed by a single administrator who as right for publishing news, events and so on...
I'd to add this feature, when the admin publishes something it's already posted on facebook wall. I'm not very familiar with facebook php SDK, and i'm a little bit confused about it.
If (make it an example) 10 different sites are using my CMS, do I have to create 10 different facebook application? (let's assume the 10 websites are all in different domains and servers)
2nd, is there a way for authenticating with just PHP (something like sending username&password directly) so that the user does not need to be logged on facebook?
thanks
You might want to break up your question in to smaller understandable units. Its very difficult to understand what you are driving at.
My understanding of your problem could be minimal, but here goes...
1_ No you do not create 10 different facebook application. Create a single facebook application and make it a service entry point. So that all your cms sites could talk to this one site to interact with facebook. ( A REST service layer).
2_ Facebook api does not support username and password authentication. They only support oauth2.0. Although Oauth is not trivial, but since they have provided library for that, implementing authentication is pretty trivial.
Please read up on http://developers.facebook.com/docs/.
Its really easy and straight forward and well explained.
Your question is so vague and extensive that it cannot be answered well here.
If you experience any specific implementation problems, this is the right place.
However to answer atleast a part of your question:
The most powerful tool when working with facebook applications is the Graph API.
Its principle is very simple. You can do almonst any action on behalf of any user or application. You have to generate a token first that identifies the user and the proper permissions. Those tokens can be made "permanent" so you can do background tasks. Usually they are only active a very short time so you can perform actions while interacting with the user. The process of generating tokens involves the user so that he/she has to confirm the privileges you are asking for.
For websites that publish something automatically you would probably generate a permanent token one time that is active as long as you remove the app in your privacy settings.
Basically yuo can work with any application on any website. There is no limitation. However there are two ways of generating tokens. One involves on an additional request and one is done client side, which is bound to one domain oyu specifiedin your apps settings.
Addendum:
#ArtoAle
you are right about every app beeing assighend to exactly one domain. however once you obtained a valid token it doesnt matter from where or who you use it within the graph api.
let me expalin this a little bit:
it would make no sense since it is you doing the request. there is no such thing as "where the request is coming from". of course there is the "referer" header information, but it can be freely specified and is not used in any context of this.
the domain you enter in your apps settings only restricts where facebook redirects the user to.
why?
this ensures that some bad guy cannot set up a website on any domain and let the user authorize an app and get an access token with YOUR application.
so this setting ensures that the user and the access token are redirected back to YOUR site and not to another bad site.
but there is an alternative. if you use the control flow for desktop applications you don't get an access token right after the user has been redirected back. you get a temporary SESSION-TOKEN that you can EXCCHANGE for an access token. this exchange is done server side over the REST api and requires your application secret. So at this point it is ensured that it is YOU who gets the token.
This method can be done on any domain or in case of desktop applications on no domain at all.
This is a quote from the faceboo docs:
To convert sessions, send a POST
request to
https://graph.facebook.com/oauth/exchange_sessions
with a comma-separated list of
sessions you want to convert:
curl client_id=your_app_id \
-F client_secret=your_app_secret \
-F sessions=2.DbavCpzL6Yc_XGEI0Ip9GA__.3600.1271649600-12345,2.aBdC...
\
https://graph.facebook.com/oauth/exchange_sessions
The response from the request is a
JSON array of OAuth access tokens in
the same order as the sessions given:
[ {
"access_token": "...",
"expires": 1271649600, }, ... ]
However you don't need this method as its a bit more complex. For your use case i would suggest using a central point of authorization.
So you would specify your ONE domain as a redirect url. This domain is than SHARED between your websites. there you can obtain the fully valid access token and seamlessly redirect the user back to your specific project website and pass along the access token.
This way you can use the traditional easy authentication flow that is probably also more future proof.
The fact remains. Once the access token is generated you can perform any action from any domain, there is no difference as ther is literally no "domain" where the request is coming from (see above).
apart from that, if you want some nice javascript features to work - like the comments box or like button, you need to setup up open graph tags correctly.
if you have some implementation problems or as you said "domain errors" please describe them more clearly, include the steps you made and if possible an error message.