We Keep Coding

Proper way of hiding very sensitive credentials in a web application

I am currently developing a spring boot web application. It is a REST api proxy that connects to another api using some very sensitive credentials. The credentials are hard-coded at the moment, but obviously they should not be. What is the proper way of hiding them?
I have considered using some library, like jasypt to encode them and put the encoded values in a properties file, with the key hidden somewhere, perhaps in system variable, (but it is just another layer of obfuscation, isn't it?)
How can I properly hide these sensitive credentials?

You can use your server environment to hide your properties. Just store on your production server application.properties with real credentials and protect access, so only your application will have access to the property file.

The fundamental problem is that if you ever need to hold security credentials in the clear in the memory of a computer program, AND there are people who have the equivalent of "root" access to the machine, then it is possible for one of those people to gain access to the credentials.
So you need to design your security so that that the credentials never need to be held in the server's memory.
If you are really serious about solving this, you need to investigate Hardware Security Modules. However, the HSM approach is going to be complicated and expensive, and may require you to rework your authentication protocols.

SSO Frameworks, which one to use? when we need?

I have been looking about SSO [Single Sign On] solutions around StackOverflow and in Google.
The concept is pretty much simple as "Once logged in, logged in everywhere"
Now my question is, as there are many different frameworks, do we really need such frameworks or can we implement simple SSO solution based on fundamental concepts or in which case we can choose what?
Two Cases:
Internet, where we expose our web applications over internet to
wide-range of people/customers, where we can have multiple domains,
multiple servers.
Intranet, where we expose out web applications over
intranet/internet to limited range of people. A better example could
be A SSO for Employees within Organization
A case where I am lying myself to find a solution.
I want to implement a SSO for employees of my organization, where they
can login to once, they will be automatically logged in all other
applications like [mail/chat etc..].
Primarily we use LDAP for User
Credentials Management. Being said that, now each application can
login by validating user against LDAP and go on.
Or
We can have a
single web application which will communicate with LDAP to login and
work as SSO with other applications talking to it.
I am making two options here.
Using one of the frameworks [OpenAM/JOSSO or any other if it's good
and fit enough for my requirement], which uses my own authentication
[my own jar which takes username and password and returns authorized
or not]
Using my own web application, which uses my own authentication as I
said and holds public/private key-mechanism [OpenPGP], and
communicates back and forth with other applications and cookie
management.
Which option is far better for my requirement, or an overview in which case we can opt for which framework?

Building your own implementation is a bad choice for at least two reasons:
others can't easily integrate with your sso provider
you can't be sure that your protocol has no hidden issues
Picking a builtin framework on the other hand is not as important as it sounds. The most important thing is to pick a well established protocol, to name three: OAuth2, SAML2 and WS-Federation.
Picking a protocol between these three leaves you with a decision: either to pick an existing implementation of the protocol or to write a custom one. The first option is of course easier to maintain and safer, create a custom implementation only when you are 100% sure that existing implementations do not fulfill your requirements.
All mentioned sso protocols work by making one particular application in your environment the identity provider. The IdP knows where to find the user backstore and how to validate credentials and other applications trust the identity provider. The difference between protocols is how the trust relation is implemented. In short, the trust in oauth2 consists in a direct calls between the application server and the identity provider server whereas ws-federation and saml consist in passing a digitally signed xml, a token which says who the user is and what roles he/she has.

Webservice Security - what is enough?

I am looking to expose a Web Service which can be called by multiple clients to retrieve transactional data. Each calling client will retrieve a different subset of data.
We are hosting the Webservice in Websphere 7 - the external webservice is essentially a proxy to the real WS running on our ESB platform.
Currently I have the following security in place:
1) WS-Security username/password sent in the header (plantext). This is authenticated against our custom repository (the repository is in-use elsewhere and has been security tested).
2) HTTPS
3) Restricting calling IPs via firewall
4) Payload data is PGP encrypted using the clients public key
Is this secure "enough"? I'm pretty sure the payload data is secure, but I'm not completely sure if the access mechanism is 100% secure? We are using what is built-in to IBM Websphere for #1.

Well, as your are using HTTPS you don't have to worry about sending the passwords in plaintext. So as long as your authentication works properly (you say the repo was security tested) this is quite secure.
Additionally you have encrypted payload using PGP, which is really secure - at least as long as all parties handle their keys with the needed care.
--> What you're describing sounds fairly solid to me, especially with the asynchronous encryption of PGP which is basically not attackable (unless you consider social engineering).
Maybe a last thought (but I guess you don't need this advice):
I don't know about Websphere, but in other application servers or ESBs (e.g. JBoss) there are some admin tools activated per default which tend to be freely accessible via the web (just google for /jmx-console ...). Make sure to secure those with passwords or deactivate them if need be.

For me it is more than enough. The only additional thing I can think about is using temporary passwords. See RSA for details.

Is the subset of data which is returned by the service linked to the authenticated client identity, or is the returned set of data determined by a parameter which gets passed in?

Secure Java Web Services

I am trying to figure out which framework/API would be best for implementing my web services (Java EE). The data being passed back and forth between client and web container needs to be super-secure, and so I'm even thinking of encrypting my data before it even gets wrapped up in a SOAP (or the secure equivalent to SOAP) message, regardless of what security services the framework provides me with.
I see there is the so-called XWS-Security but it seems that it is for securing legacy JAX-RPC services. I'd like the framework to be standards-compliant (WSS/OASIS, etc.) and neither deprecated or deprecating (current; compatible with the upcoming Java 7 release, etc.).
Is JAX-WS and JAX-RS secure by default? If not, is there a compatible "secure wrapper" framework that can be used to adapt an existing JAX-WS web service to implement a secure framework?
Any thoughts or suggestions greatly appreciated!

If you just want to secure the content then use transport layer security, such as HTTPS. This will automatically encrypt WS request/responses and prevent evesdropping and malicious modification.
If you want to do any authentication/authorisation you might want to get the caller to sign the request too.

You should do two things, first secure the transport using SSL. If you control both the clients and the server then you can require 2-way SSL which would ensure that only trusted clients can connect.
Second you can implement WS security protocols. Web service security standards tend to deal with three things: Authentication, Digital Signatures and Encyption/Decyption (from the Spring-WS docs):
Authentication. This is the process of determining whether a principal is who they claim to be. In this context, a "principal" generally means a user, device or some other system which can perform an action in your application.
Digital signatures. The digital signature of a message is a piece of information based on both the document and the signer's private key. It is created through the use of a hash function and a private signing function (encrypting with the signer's private key).
Encryption and Decryption. Encryption is the process of transforming data into a form that is impossible to read without the appropriate key. It is mainly used to keep information hidden from anyone for whom it is not intended. Decryption is the reverse of encryption; it is the process of transforming of encrypted data back into an readable form.
There are a number of protocols/standards for each of these functions, and
there are a number of Java OSS projects that implement the various security protocols/standards in a reasonable, usable ways.
In particular I'd look at Sun's XWSS and APACHE WSS4J. Spring WS has implementations of both of these APIs, they also do a good job of describing the various components: http://static.springsource.org/spring-ws/sites/2.0/reference/html/security.html

How to write a java web service to do remote login?

I have two application. I need to do a single signon from application a to application b.
I thinking of using web service. I wonder how do i go about that approach.
Can anyone advise?

Assuming these are web applications - you must implement some type of shared trust model between the applications.
Under no circumstance should you write your own. That is too easy to screw up and there are plenty of existing (both open and commercial) to choose from.
Here are following options:
1 - If everyone is running Windows - you could just Windows Native Authentication (aka SPNEGO)
2 - You could implement some type of SSO system. Popular systems are CAS, Oracle Access Manager, CA SiteMinder, Sun SSO and IBM Tivoli Access Manager. While CAS is open-source, the others will also allow you to implement authorization as well, while CAS only does authentication.
Finally - make sure whatever option you choose - that it integrates with your language's native authentication & authorization framework. In Java this would be JAAS. In .NET it would be the .NET security framework. For PHP/Perl - you can leverage Apache modules. The benefit is that you don't have to become a security expert and it will make it easier to use external systems for authentication & authorization without having to re-code your app.

You could use a public key authentication scheme.
Create a keypair with a public and private key (using Java's keytool, GNU GPG or a similiar tool). Use the private key to sign a piece of information (for example a username) on application A and create a link to application B that is accessible from application A and contains the signed data. Application B can then log the user on after verifying with the public key that the request indeed came from application A (which it must have if it is able to decrypt the string).
You could of course create a opposite keypair for navigating the other way as well, or you could just use the public key and keep it secret (effectively making it a shared-secret system).
If the user tries to access application B directly you could also redirect him to application A with a parameter that says he came from application B (or do a referrer check). If he is already logged on to application A create the link with the signed data and redirect to it, otherwise present him with a logon screen and redirect after logon.
Hope that helps!

You could use an existing open source product, CAS and just implement it instead of develop your own. That way you'll be able to integrate with other applications that support the same protocol. Even if you decide to implement your own instead of using their code, there are a lot of ideas presented at the web site that would be useful for you to consider.

If the applications are hosted in the same server, then you could configure it to use single sign on. For example, in Tomcat this is achieved with a Valve.
If the applications are in different environments, then a secured Web Service is a good idea. You could for example create a public - private key pair and have application b (server) authenticating application a (client) on the client certificate. This means that application a will sign all requests to application b with the client certificate. More details about the architecture are needed for a full solution.

Are you using an application server? What is the environment for your applications?
There is a standard for propagating identity using web services called Web Service Security UsernameToken Profile. Here's a quick overview. You can send username/password or various tokens such as X.509 certificate or a SAML assertion. Some application servers web services stacks will handle WSS UsernameToken Profile, JBoss, Websphere, and WebLogic. Otherwise the web service code has to handle it. This approach may be too cumbersome depending on your environment.
There is a standard for single sign-on, called SAML. Again, this may be too heavy weight for your use-case.

In Oracle land I know there is the concept of a trusted application. Basically if you have control of both applications you can set it up like so:
Application A sends Application B, 1) Application A's username and password and 2) the current user's username. Since B knows and trusts Application A it doesn't need to verify the user's credentials, since it knows application A has already done that for it.
I assume that if you have a custom application B you might be able to do something like this. If your SSO implementation supports this then you probably don't have to do a whole lot except design your web services.
Good Luck