Our project is going to implement SSO recently, and I learned about some SSO methods and products, CAS is the very one I want to use, but some questions of our member I cannot answer, hope the authorities can help here:
Since CAS server TGT cookie is stored in the browser, once it's stolen or be copied to other machine, the other people can also login the WebApp as long as the TGT is not expired.
So, any method to protect against this scenario? or how should I consider about this scennaro?
Besides, what's the essential difference between cookie sharing sso (for example Webapp A and B combined by nginx) and CAS, since they are both based on cookies ?
The cookie is encrypted and signed. If it gets stolen, it's always cross checked against what the server knows.
Related
Hoping someone can remedy my naivety when it comes to calling a simple URL to an application (which returns XML) using NTLMv2.
I have read pretty much every question and page there is but I am left with one overriding curiosity. I am using the HTTPClient at present (although this can be changed) along with the latest JDK (at the time of writing).
Here is an example page which appears to call the JCIFS library:
http://hc.apache.org/httpcomponents-client-ga/ntlm.html
All looks good, albeit confusing, but this highlights the question that many of the examples I have seen raises - the issue of supplying NTCredentials.
To me the whole point of NTLM is so that I do not have to supply credentials. The target aplication is set up to use NTLM so surely the user credntials of the currently logged in user should be used? Why should I be supplying any credentials myself?
Apologies if I am missing something obvious here. I just need the most basic for of NTLM SSO possible using Java. I don't care what version of what, I am able to use the latest of anything.
Holding out hope! Thanks for reading.
Unfortunately, there's way to do single sign-on in a pure Java environment.
NTLM isn't a solution to single sign-on directly. NTLM is a challenge/response authentication mechanism and it requires the NTLM hash of the user's password. Windows machines are able to provide single sign-on using NTLM because the NTLM hash is persisted. They are then able to compute the response to a challenge based on the persisted hash.
Without access to that hash (and, to my knowledge, you can't simply request it) you need to compute it yourself. And that requires having the user's password.
Similarly, you can do single sign-on with a Kerberos ticket using SPNEGO authentication (if the remote system is setup to support it, of course) but Java unfortunately reimplemented Kerberos instead of using the system Kerberos libraries. So even if you were already logged in to the domain, you'd need to go get another Kerberos ticket for Java. And that means typing your password in again.
The only realistic way to avoid typing in a password to authenticate is to call the native methods. On Windows, this is SSPI, which will provide you the ability to respond to an NTLM or SPNEGO challenge. On non-Windows platforms, this is handled by the very similar GSSAPI and provides the ability to respond to SPNEGO (Kerberos).
I am currently working on a REST/JSON API that has to provide some services through remote websites. I do not know the end-customers of these websites and they would/should not have an account on the API server. The only accounts existent on the API server would be the accounts identifying the websites. Since this is all RESTful and therefore all communication would be between end-user browser (through javascript/JSON) and my REST API service, how can I make sure that the system won't be abused by 3rd parties interested in increasing the middleman's bill? (where the middleman is the owner of the website reselling my services). What authentication methods would you recommend that would work and would prevent users from just taking the js code from the website and call it 1000000 times just to bankrupt the website owner? I was thinking of using the HTTP_REFERER , and translate that to IP address (to find out which server is hosting the code, and authenticate based on this IP), but I presume the HTTP_REFERER can easily be spoofed. I'm not looking for my customer's end customers to register on the API server, this would defeat the purpose of this API.
Some ideas please?
Thanks,
Dan
This might not be an option for you, but what I've done before in this case is to make a proxy on top of the REST calls. The website calls its own internal service and then that service calls your REST calls. The advantage is that, like you said, no one can hit your REST calls directly or try to spoof calls.
Failing that, you could implement an authentication scheme like HMAC (http://en.wikipedia.org/wiki/Hash-based_message_authentication_code). I've seen a lot of APIs use this.
Using HMAC-SHA1 for API authentication - how to store the client password securely?
Here is what Java code might look like to authenticate: http://support.ooyala.com/developers/documentation/api/signature_java.html
Either way I think you'll have to do some work server side. Otherwise people might be able to reverse engineer the API if everything is purely client side.
[I read all the similar questions previously answered, but the answers seemed rather conflicting. Please do only respond if you are 100% certain of the answer to prevent further confusion ;-) Thank you!]
We are planning to create facebook apps for clients.
Is it possible to use the same sub-domain for all apps in a way that requires a basic SSL certificate for all apps, so that a basic SSL certificate would suffice? (making it much more time and cost efficient for us)
If not, what would be the most time and cost efficient way to do it?
Using a wildcard SSL certificate?
Or a unified communication certificate?
And does anyone have a great recommendation where to best get the kind we need, obviously one acceptable by Facebook?
Thank you so much for your help!
You can point all of your applications to the same sub-domain and just have each application residing in a different folder.
As you said - you must ensure that this domain has an SSL certificate implemented on the server..
I want to implement a discrete remote authentication server that handles login for many sites. Somewhat similar to OpenID.
Basically, I have site-1 and site-2 and they're both reliant on the same user database, which is on a separate auth-site. So, auth-site handles user authentication for them, and during this process, makes information on the authenticating user available to the requesting system.
Each site can be on a completely separate domain name, on completely separate machines.
This is all via HTTP(S), there can be no direct database access.
There's one last quirk: once an user has logged in to site-1, when accessing any other site reliant on auth-site, the site must treat the user as already authenticated.
This whole business must be entirely fuss-free to the end-user. It should work like a simple everyday login form.
As a concrete example, say we're talking about stackoverflow.com and serverfault.com, and they both authenticate via authentic-overflow-server-stack.com. Again, once logged in to either site, I can go to the other and do my business without logging in again.
What I'd like to know are the general interaction mechanism between the sites behind this scenario.
In my particular setup, I'm using Rails, but I'm not looking for code[1], just general best practice and guidance, so feel free to answer in pseudo-code or any generally readable language. OTOH, bear in mind that I'll have decent MVC, REST, and meta-programming in my toolkit.
[1]: unless you happen to know an existing tiny neat free MIT/BSD-licensed app/plugin/generator that handles this.
It sounds like (especially with the emphasis on fuss-free), you want something like what the Wikimedia Foundation is doing. Basically, you log on to en.wikipedia.org, then that server communicates with other servers (e.g. en.wikinews.org) and gets authentication tokens. Finally, those tokens are embedded into images, e.g. http://en.wikinews.org/wiki/Special:AutoLogin?token=xxxxxxxxxxxxxxx , and when your browser visits that url (img src) it gets a authentication cookie for Wikinews. Of course, the source code is available for your reivew at http://www.mediawiki.org/wiki/Extension:CentralAuth .
OpenID is also a good choice, but it does require that the user "consciously" visit two domains. An example of one entity with two domains doing this is Canonical. E.g., if you go to https://help.ubuntu.com/community/UserPreferences they will redirect you to Launchpad (https://login.launchpad.net/+openid) for authentication.
Note that Wikipedia is doing this over http, but you can do it all https to ensure the img src tokens aren't intercepted.
Looks like CAS is good enough for me, and has ruby implementations, along with dozens of other lesser languages, e.g. one that rhymes with femoral bone rage.
http://code.google.com/p/rubycas-server/
http://code.google.com/p/rubycas-client/
It sounds like you want to actually use the OpenID protocol itself. There's no reason you can't restrict the authentication provider to only your own server, and do some shortcuts that make the authentication process transparent. Also, the OpenID protocol supports what you describe about logging into one implies logging in to all services.
Not sure if the title is quite right for the question but I can't think of any other way to put it..
Suppose you wanted to create multiple different web apps, but you wanted a user who was logged into one app to be able to go straight to your other app without re-logging in (assuming they have perms to look at the other app as well). If I'm not mistaken, if you're logged into gmail you can go straight to your iGoogle, googleReader, etc without re-logging in (if you set it up right).
How would you approach this? What would you use? Assume the apps already exist and you don't want to change the initial login page for the users.
What you're looking for is called Single Sign On. If you follow the link you'll find several implementations.
Open ID as others have mentioned is not such a scheme as it requires a seperate login for each site. Open ID is merely a shared authentication system.
You would issue a cookie against foo.com, which would then be visible on app1.foo.com, app2.foo.com.
Each application can then use the cookie to access a centralised authentication system.
Try CAS it should provide the features you are looking for.
What you want is a single sign-on (SSO).
There are two approaches to solving this problem:
Roll your own implementation. In its most trivial form it can be implemented by the first site setting a cookie that holds the ticket for the logged on user and the second site verifying that ticket and accepting the logged on user. There are quite a lot of potential pitfalls here:
you have to protect yourself against information disclosure - make sure that the ticket does not contain the actual user credentials
you have to protect yourself against spoofing - a man in the middle stealing a valid ticket and impersonating one of your users
and others
Adopt a third party SSO mechanism. Google, Microsoft, Facebook and other big companies allow integrating with their identity providers, so that your users could log on to their website and they handle verification, ticket issuing and so on. There's also OpenID, which is an open protocol you can use to enable SSO on your site through virtually any identity provider that supports OpenID. The potential drawback here is that somebody else controls your access to your user identity and can limit the features you can offer and data you can mine for your users.
As mentioned you can use something like OpenId or similar to make the process simple. Otherwise if you roll your own you could use a cookie to store the login, then basically ALL applications must have an entry point that mimics the base url.
Google for example uses mail.google.com to as a pipline into Gmail which allows it to read a cookie stored with the google.com domain.