This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Propagating client identity  RSS feed

 
Rick Smith
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I've been looking into the not-so-small area of user authentication over the past few days, I certainly will not claim to understand much of the topic, but hopefully enough to be able to articulate the question I am trying to answer.

The short version is: In a wider set of applications supporting single sign on, how might one of those secure web-application, propagate a set of sub-tasks out to one or more other services which MUST account for the originators access rights.

For example:
A user uses my JEE web-application to send some notification message to a set of a companies registered customers, my web application would attempt to use service A to look up a list of customers and service B to send the message by some mechanism. In this example, service A is only allowed to provide a limited set of users because of some business rule enforced by service A and perhaps service B will decide how to send the message based on the priority of that particular users.

If this problem was solved with an EJB or more sophisticated web-service solution mechanisms are in place to pass the identity through, e.g. http://docs.sun.com/app/docs/doc/820-7627/bnbyr?a=view or we my use the the approached such as http://en.wikipedia.org/wiki/Federated_identity however these require specific things to be in place in the overall system to support (SAML, Identification Provider etc), and will not easily support legacy services (Which provide simple e.g. RESTfull interfaces).

The nieve approach that comes to mind would be that my service simply makes the appropriate connection(HTTPS)/request against the down-stream services and leaves it to my applications container to fulfil the authentication challenges that the target service would make, however I do not believe that the container (eg. tomcat) would either handle the challenge as I expect, or if it did, it would handle the challenge as a different users, not the original client requester meaning the connection would fail, or be created with the incorrect access rights/id.
To do this my apps container would either need to be clever and negotiate the connection with the target container (is this in built in the JEE specification), or package the security id/key (Keberous TGT) in the request so the down-stream service thinks the connection (session?) has been authenticated (is this even possible?). However these could easily be construed a security issues, the caller (be that client originator or intermediate service) should be authenticated itself, and should probably not pass on its clients security details.

An approach along these lines might not be the rightmodern approach, but given the potential restrictions on a hosting environment and legacy services doe sit introduce a security risk or fundamentally inconsistent with the way these aspect of JEE work.

Any comments, thoughts or opinions would be appreciated.
 
Rick Smith
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Perhaps I should have put this question in the Security section?]


Perhaps a better question to clear up the fundimental issues would be:

If the business logic of a secure web-application calls another secure web-application (available as a RESTful service interface) to service a clients request what happens?

- The calling service must be challenged by the down-stream service?
- Assuming so what credentials does it provide?
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have recently implemented something of this sort using Weblogic and SAML.
I would think that even if your application server does not support SAML out of the box, the concept behind it can be implemented through custom code. Basically the downstream app looks up an assertion that is provided by the upstream app (where the authentication happened upfront).

ram.

Edit : Reading the original post again, I see that you have mentioned that these apps are connected through SSO. It's a little puzzling because why would a set of apps connected through SSO need to ask (within that group) for authetication again? Isnt that what SSO means?
 
Rick Smith
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ramprasad madathil wrote:We have recently implemented something of this sort using Weblogic and SAML.
Edit : Reading the original post again, I see that you have mentioned that these apps are connected through SSO. It's a little puzzling because why would a set of apps connected through SSO need to ask (within that group) for authetication again? Isnt that what SSO means?


Ram, Thank you for you reply, from what you have said and many other forums SAML (Federated identity etc) seems to be the preferable way to addresss this problem, but in this case I would not have the ability to update the down-stream apps to account for it, my service is simply delegating taks out to a set of other (legecy) service providers and would have to work along with whatever security they had implemented (most of which will be SSO but some may be publicly available).

My limited understanding of SSO is that the actual client is authenticated, and can then access my application, or directly access the other services by providing some sort of key/ticket. A user session would exist between the client (IE) and which ever component it formed a connection to. But when my application uses a service on behalf of the client the session only exists between it and my app, any onways connections would in effect be different user session (between my app and a service), that service doesn't know about the client, e.g. if and what access should be granted.

Or am I wrong, is there a way to extend/pass through the session on to the services?
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A user session would exist between the client (IE) and which ever component it formed a connection to. But when my application uses a service on behalf of the client the session only exists between it and my app, any onways connections would in effect be different user session (between my app and a service), that service doesn't know about the client, e.g. if and what access should be granted.


Rick, you are right about the sso part. As far as I Know - sso, saml and other standards that address federated identity primarily addresses the issue of a browser based interaction between partner sites. So for example, you have a user authenticated on one site and then on the browser you click a link that takes you to a partner site and there's a need to propagate the identity along to the other site - that's what all these standards address.

But if I am not mistaken, I read your problem thus

User A is logged on to Site 1 from a browser. (Session 1A)
User A is logged on to Site 2 from a browser. (Session 2A)

User A does some action on the browser which request goes to Site 1.
Site A as part of it's request processing needs to call a service on Site 2.
When this inter-site call (maybe a Restful web service or anything on these lines) is made from Site 1 to Site 2, there is a need to proagate the user's session on that site.(Session 2A above).

I dont know if that can be achieved by anything other than custom code on both apps. If and when SSO happens between the 2 sites initially, the sites have to exchange their respective identities with each other through a custom handshake protocol. Once that is achieved, this identity reference to the other site can be used in all communication between the systems.

ram.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!