How to write a java web service for remote login?

I have two applications. I need to make one signon from application a to application b.

I am thinking about using a web service. I wonder how I approach this.

Can anyone advise?

+6
java web-services
source share
6 answers

Assuming these are web applications - you should implement some model of sharing trust between applications.

Under no circumstances should you write your own. It's too easy to drown out and there are many existing ones (both open and commercial) to choose from.

Here are the following options: 1 - If everyone is running Windows - you can only use Windows Native Authentication (aka SPNEGO) 2 - You can implement some type of single sign-on system. Popular systems include CAS, Oracle Access Manager, CA SiteMinder, Sun SSO, and IBM Tivoli Access Manager. Although CAS is open source, others will also allow you to implement authorization, while CAS does authentication.

Finally - make sure that whatever option you choose - it integrates with your own authentication and authorization in your language. In Java, it will be JAAS. In .NET, this would be the .NET security infrastructure. For PHP / Perl, you can use Apache modules. The advantage is that you do not have to become a security expert, and this will simplify the use of external systems for authentication and authorization without the need to re-encode your application.

+3
source share

You can use a public key authentication scheme.

Create a key pair with public and private keys (using Java keytool, GNU GPG or a similar tool). Use the private key to sign part of the information (e.g. username) in Appendix A and create a link to Appendix B, accessible from Appendix A, and contain signed data. Application B can then register the user after verifying with the public key that the request really came from application A (which it should have if it is able to decrypt the string).

You could, of course, create the opposite key pair to navigate a different path, or you could just use the public key and keep it secret (effectively turning it into a shared secret system).

If the user is trying to directly access application B, you can also redirect him to application A with a parameter that says he came from application B (or does a referrer check). If it is already registered in Appendix A, create a link to the signed data and redirect to it, otherwise, provide it with a login screen and redirect it after you log in.

Hope this helps!

+2
source share

You can use an existing open source product, CAS, and simply implement it, rather than developing your own. Thus, you can integrate with other applications that support the same protocol. Even if you decide to implement your own, rather than using their code, the website will present many ideas that will be useful to you.

0
source share

If the applications are hosted on the same server, you can configure it to use single sign-on. For example, in Tomcat this is achieved using Valve .

If the applications are in different environments, a reliable web service is a good idea. For example, you can create a public and private key pair and have application authentication application b (server) (client) in the client certificate. This means that application a will sign all requests to application b with a client certificate. More detailed architecture information is needed for a complete solution.

0
source share

Are you using an application server? What is the environment for your applications?

There is a standard for identifier distribution using web services called the UserToken Profile theme. Here is a quick overview . You can send username / password or various tokens such as X.509 certificate or SAML approval. Some application server web service stacks will process the WSS user profile UsernameToken, JBoss, Websphere, and WebLogic. Otherwise, the web service code must process 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 for your use case.

0
source share

In the Oracle field, I know that the concept of a trusted application exists. Basically, if you have control over both applications, you can configure it like this:

Appendix A sends Appendix B, 1) Appendix Username and Password, and 2) current username. Since B knows and trusts Application A, he does not need to verify the user credentials, since he knows that application A has already done this for him.

I assume that if you have custom application B, you can do something like this. If your SSO implementation supports this, you probably won't have to do much other than design your web services.

Luck

0
source share

All Articles