Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm starting to work on a SSO solution for 3 different webapps we've produced and still maintain for the same client.
Thing is, all 3 store their users and login information in the same place through a fourth separate application which provides just basic restful api services.
Which basically means that when one tries to log into, we actually call the rest service asking whether this username and password are correct.
In a way this fourth restful thingie already does at least half of the job we need.
What we need now is a way to let users log into webapp A, then follow a link (or simply type its url) to webapp B (or simply type its url) and get there already logged (or viceversa).
I've been reading a lot about CAS and openID or even oauth but can't really make up my mind about it.
Is this pattern centralized? Decentralized?
My ten-thousand foot view suggests I would somehow just need to add this "missing feature" to our restful api server.
But how?
ps: these 3 are completely separated. deployed on different machines (2 of them run on glassfish, the other one runs on tomcat). different domains too.
pps: they're all spring-driven webapps (hence they use spring-security)
ppps: as of today, there are other webapps using our restul api (non spring, non java).
this sso solution might have to be ready to handle those too.
Yeah it sounds like you need a "true" single sign on system rather than just a centralized credential repository. As you mentioned there are several options:
OpenId - more suited to an internet type application in which you
want to allow users to log into your systems with credentials that
are maintained by a third party. Stackoverflow is a classic example.
You can sign in with your google account etc.
Oauth provides Pseudo authentication and sso - whereas OpenId says
"this is user x" oauth says "this user has access to x's
information" ... so you can assume that the user is x.
CAS, Cloudseal, OpenAM etc all provide true single
sign on and are suitable for an intranet or extranet environment.
CAS and Cloudseal have especially good Spring support.
Trusted site (relying party (RP) in white list - app a,b,c in your case) make request (redirect) to main site (provider - "fourth separate application") with a return url.
Main site make sure request (returnURL) is from white list of domains
Log user (if not logged, displaying login form), mark user as logged in database and add temporary token to user database.
Main site return (redirect) to RP with token.
RP look into database using token, logs user and deletes token.
SSOff also easy: just check on every request into user database into bool record (userLogged). NO REDIRECTS. On logout simply change record (userLogged) to false and every site will know.
Related
I have a problem with the Docusign embedded Edit View.
My application connects to Docusign via JWT. Using the API, I'm allowing users to edit existing envelopes (when in draft) through my own application. The redirection to docusign works fine and the users are able to edit an envelope, adding/removing recipients, setting the signature blocks, etc. All good there. My problem is with the callback.
Using the ReturnUrlRequest, my callbacks are successful and after editing an envelope, users are redirected back to my application. The problem is that before this happens, for a few seconds they are looking at the Docusign inbox for the account. This is a security issue and could allow users to see privileged information, as if they send an envelope after editing it, they'll be looking at the sent folder and can see all other recent envelopes. I presume they could also stay in the inbox and do whatever they wanted if they click on an entry quick enough, but I haven't confirmed this yet.
I need the callback to go directly from the envelope edit to my application, and prevent anything else from docusign from appearing. Is there a way I can lock this down?
And yes, I know that this is something I shouldn't be doing in any event, and that my basic problem is that I'm using the edit view in the first place. I don't have much of a choice. I originally implemented things using the API and my own application provided all of the configuration options on their own. The client, however, didn't like this and essentially demanded that their users be allowed to use the Docusign system's own editing suite, as that is what they are familiar with. I'm trying to square the circle as best as I possibly can.
As per the Information Security Notice on the linked page, the Create Edit View provides fully authenticated access to the sending user's account. Even if you were able to prevent the brief view of the inbox, a savvy user could 'break out' of the edit view by navigating directly to app.docusign.com (or appdemo.docusign.com in the sandbox) because their DocuSign session is still valid.
The only way to 'secure' this is to provision each sending user their own membership on the DocuSign account so that users cannot see each other's envelopes (unless explicitly allowed to do so via Document Sharing).
In addition to Drew's answer: please ask your DocuSign account rep or customer service contact to add your customer information to internal ticket EC-1009. That will help raise prioritization of providing a secure edit screen for applications to use.
This question already has answers here:
How can I suppress the browser's authentication dialog?
(12 answers)
Closed 5 years ago.
First of all, I'm not 100% sure what I'm asking is a right thing to do or not. So please free feel to correct me if I'm wrong.
Using Spring Security, I've developed a REST API backend which users can log in using some custom entry. If my users authenticate themselves using my custom API, there will be a session created for them and the rest of API entries will be accessible to them, considering their role and ACL.
At the same time, these APIs are designed so they can provide services to other software. So I thought it makes sense to enable some HTTP Basic Authentication as well. Later on, I might be working on digest as well. And if some request is authenticated using one of these methods, there will be no session created for them. And they'll need re-authenticate for every single request. It's a stateless API.
So far everything is great. The users and other systems can make use of the same sets of APIs. But the problem is when a user's session is expired. Or when some user starts using the backend services before he logs in. In such cases, the right strategy is to redirect the user to a login page and ask them to authenticate themselves. But since I've enabled the HTTP Basic Authentication, calling a REST API which needs authentication (while the user is not authenticated) leads to a browser popup asking for the username and password.
Of course, the user can enter the credentials and keep using the system. But I don't like this way of authentication for my users. First of all, the authentication credentials will stick and I consider it a security risk. They are easily be saved into the browser without informing the user they are. And it's hard to get rid of the saved credentials. The user can leave the computer without even knowing that his username and password are saved.
So my question is, is it possible to have Basic Authentication enabled but at the same time, prevent the browser from knowing it? Or even better, acting on it?
I suspect that if I prevent the WWW-Authenticate response header on the way back, I might be able to do so. But then, I'm not sure of the ramifications of such a decision. Also, I don't know how to remove that header from the response for all of the APIs.
I think I rushed into asking a question without researching it thoroughly first! This post answers it perfectly!
How can I supress the browser's authentication dialog?
The solution: add a X-Requested-With: XMLHttpRequest header to your request.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am developing a REST API with Java using Jersey and what is the best way of securing it? I looked at various things from password based authentication, Servlet Context , and I heard about tokenization and so on. But what is the industry standard way to secure it and make sure nobody can get data from a GET request by just typing the URL in browser, simply make a POST calll from PostMan and so on? Any learning materials on implementing this best way?
In simple English, what i am asking is, how can I secure my REST API by making sure the API is accesible only to our app?. The method of doing it can be anything from password to token. I am learning it now trying to implement it, but before I need to know what to learn, because I am looking for the best practice and industry standard way of doing so.
Here is pretty good place to start to secure your API:
Use HTTPS
Use username/password for authentication
When user successfully logs in, you generate a token for them
Assign the token to that user (easy way is to save it in a DB)
Require the user to send that token with every request
Validate the token before responding to any request
That being said there are some concerns. You should research how to achieve these:
Store credentials in your DB in an encrypted form in case your DB is compromised.
If you store your tokens in a DB, validation requires a DB lookup, will that be an issue, are you expecting heavy load?
If you use a stateless authentication, for example a JWT then how do you revoke access if you need to. (Hint: look into access+refresh token scheme + a blacklist)
How do you transport your token(s), header, cookie?
Protect your API from cross site scripting(a.k.a. XSS) and cross site request forgery(a.k.a. CSRF or XSRF).
NOTE: these are just some quick thoughts off the top of my head, you can find a lot of information about these online.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have multiple java web applications all having their login functionalities. I want to apply SSO(Single Sign On) on them irrespective by any method.
I have spent last 2 days on finding a solution to it, but I have no result.
Please anyone can help me on that.
My requirement is:
1.If user logs onto a single application he would be automatically logged onto other applications.
Sorry for my English and Thanks in advance.
If applications are in a Windows intranet and use windows logins, Waffle will do the job. Otherwise develop your own simple ticket granting service to provide SSO among your applications.
Update:
All of your apps have to have filters. Filter sends the session/cookie data(if available) in order to verify, to your SSO service whether the incoming request with the principle is already granted or not. If the session or cookie is not associateed with a ticket, then you redirect to the login page. If the request is about to login, then filter sends them in to SSO service, verify user and password with your database, and add an entry to SSO MAP, saying "this user just logged in". So it will send a ticket for that login. Ticket means just a random generated id. If the SSO service could not able to validate the user, then no entry will be there in the SSO MAP and will send failure error to your filter.
So your user validation goes in to a separate service which I just named as SSO service.
You will have to remove idle entries from SSO MAP.
Read about how SSO works, you will understand.
I want to implement a autmatic billing systen for one cybercafe.MEasning when some one want to surf net in my cafe he goes to attendent and attendent allocates him the pc and gives him the passswd which is generated by the applciation and the passswd will be valid for specific time(session of 1 hr or so depending on customer needs).Now when customer goes to his pc and opens any site he must be first redirected to my webapplication which will ask for passswd .If he enters correct details he will be allowed to surf the net for that particular and if his time expires he has to get the timer renevewd fro attnedent or else he cant serf.
In short i want a readymade proxy server module in java that i can combine with my webapplication. As i will need to implemet billing/ autontication based on this thigs.
What approach can i use? What proxy moduels are available?
The only Java proxy server I've encountered is jsocks. It should provide the proxy features you want.
You can then write your own authentication on top of this to make it behave you want with regards to time based logins e.t.c. Quoting from the jsocks page:
Authentication scheme is rather
simplistic, but can be extended, if
you know how to program in Java.
I would use CoovaChili or some other captive portal and then work the RADIUS part into the billing application.