Archived
This forum has been archived. Please start a new discussion on GitHub.
Authentication support for SSAPI or Kerberos?
I've been operating in the CORBA world (specifically TAO) for some time now and have made a decision to shift focus towards a more stable and consolidated (specifically that all of the language bindings are bundled inside a single product solution) platform like ICE.
SSL is a reasonable solution for privacy, but in terms of security and authentication its (IMO) an easily deployable for many enterprises (certificate management, revocation, etc). Addtionally, firms like mine have a vested interest in having a single-signon model for their systems.
So, does ICE (or has anyone done) provide support or the means to support a single-signon model. Has anyone had any experience connecting that to NTLM or even a GSSUP implementation.
Lastly, I see that Glacier has support for "login", but its unclear to me how that login process generates any credentials that can be used at a downstream system. I'd really like some comments on this because while privacy is nice, authentication is necessary.
Thanks.
SSL is a reasonable solution for privacy, but in terms of security and authentication its (IMO) an easily deployable for many enterprises (certificate management, revocation, etc). Addtionally, firms like mine have a vested interest in having a single-signon model for their systems.
So, does ICE (or has anyone done) provide support or the means to support a single-signon model. Has anyone had any experience connecting that to NTLM or even a GSSUP implementation.
Lastly, I see that Glacier has support for "login", but its unclear to me how that login process generates any credentials that can be used at a downstream system. I'd really like some comments on this because while privacy is nice, authentication is necessary.
Thanks.
0
Comments
-
crackajaxx wrote:I've been operating in the CORBA world (specifically TAO) for some time now and have made a decision to shift focus towards a more stable and consolidated (specifically that all of the language bindings are bundled inside a single product solution) platform like ICE.
SSL is a reasonable solution for privacy, but in terms of security and authentication its (IMO) an easily deployable for many enterprises (certificate management, revocation, etc). Addtionally, firms like mine have a vested interest in having a single-signon model for their systems.
So, does ICE (or has anyone done) provide support or the means to support a single-signon model. Has anyone had any experience connecting that to NTLM or even a GSSUP implementation.
Lastly, I see that Glacier has support for "login", but its unclear to me how that login process generates any credentials that can be used at a downstream system. I'd really like some comments on this because while privacy is nice, authentication is necessary.
Thanks.
The Glacier login process uses an interface called PermissionsVerifier, which can be implemented by your application, to validate the provided username and password. You could provide an implementation of this in your application to validate the username/password through Kerberos.
Next, I would use Glacier sessions. Each session has a set of associated Kerberos credentials. Each call by the client on the back end server has to go through the session object, or some facade provided by the session object. The facade receives the Kerberos credentials from the session itself. Each call on the back end through the session or facade first validates the Kerberos credentials and granted tickets. Glacier provides a number of guarantees about security, if suitably configured, so that your application can ensure that a session is not hijacked (meaning that this approach should be safe) and that the client cannot call directly upon back end server objects (or to be more precise can only call upon those objects that your application exposes). I recommend reading the Ice manual and seeing the two Connections columns that I wrote on this topic.
The problem with my suggested approach is that the Glacier session creation process is separate from the username and password validation. This is somewhat inconvenient, but not impossible to work around. For example, you could collocate the PermissionsVerifier with the session manager. In this it would be a simple matter for the session manager to retrieve the previously established Kerberos credentials from the PermissionsVerifier upon session creation.
If you have further questions please don't hesitate to ask.
If you need a custom solution developed to make this process easier or more transparent then please contact us at info@zeroc.com.
Regards, Matthew0 -
Ah, this is pretty good news to hear, but I do still have a couple questions. What you've suggested handles the login sequence pretty handily. The router receives the login forwards it to our PermissionVerifier and then creates a Session after verification is complete. The client then makes a call which goes through the Session or facade.
If I were doing authorization at the session or facade that would be fine, but there are many classes of systems that have to know the credentials of the caller at the servant. My guess is you'll tell me I can add some of that information to the context prior to sending it to the servant, and if so that's an acceptable answer as well.
Let me present an example where we do this very operation. A user logs in, it creates a facade token, they issue a request (in this case its "getCurrentAuthUser") which returns the authenticated user information (role, credential information, etc) for the caller.
The equivalent (as I understand it -- and I've read the manual a few times now) would require that the session forward some relevant information with the request so that the servant can make that determination. Again, I'm fine with this, I'm just looking for some validation that this isn't off the wall.
Thanks again.0 -
crackajaxx wrote:If I were doing authorization at the session or facade that would be fine, but there are many classes of systems that have to know the credentials of the caller at the servant. My guess is you'll tell me I can add some of that information to the context prior to sending it to the servant, and if so that's an acceptable answer as well.
...
Thanks again.
I wouldn't recommend doing any authorization at the back end server at all. Its much easier to facade all of the calls at the session layer. In this way your back end logic doesn't have to worry about credentials - it can just worry about whatever processing that it must do.
If you need a concrete implementation, or changes to Glacier to support Kerberos natively we'd be happy to help. Please mail us at info@zeroc.com.
Best Regards, Matthew0 -
You simply can't do all authorization in a middle layer. If all your middle layer is doing is saying yes or no, then its simple. But if I make a query against an object model and the object-model has to take into account the entitlements associated with the user then the model, not the session, is the one who has to structure that.
Let me give a more concrete example. Two users login, get their session, grab an object inside our application domain. Lets say it returns portfolio state (i.e. orders, trades, positions). The method looks exactly the same to each of them, but the returned state varies depending upon who asks and what they are authorized (or entitled) to use. That's not something I can nor would push into a session layer because its not orthagonal to the request its a fundamental input to the process.
If the process is orthagonal to the authorization process then I'm perfectly content with not putting it into the process, but we have plenty of cases where the application domain needs to know who is making the request so that it can structure its response appropriately.
Hope that makes sense.0 -
I think in this case the cleanest solution would be to have a caller identity parameter in each relevant method call on the back-end. The identity is then filled in by the session object, which also acts as a facade. You could also use the context if you like, but personally I think an explicit parameter is cleaner.
The identity parameter itself could be a proxy to an Ice object representing the identity, which could have various methods to query role, credentials, etc. The actual implementation (i.e., whether it uses Kerberos or something else) could be hidden.0 -
Sounds like the most reasonable approach, though I wouldn't term is as the cleanest. Its just my opinion, but I think identity is so critical an underpinning that like many other things it should be orthagonal and transparent to the caller or recipient. IMO, its like a lot of things we discuss in the distributed object environment. If its clean to have authorization clearly abstracted away from the caller and servant then why is it clean to expose identity to the caller and servant (I realize I'm over-simplifying a bit, the session would actually fill in that information).
It seems like any method that requires special permissioning would thus forth need to add a parameter to its method signature. The session would need to fill in that parameter for invocations, but how would it know? It would have to look at the method signature and apply heuristics or know the method implicitly. Neither of make me comfortable because it ties identity directly with the invocation instead of it being transparent.
We wouldn't make the same argument for operations on a file system. open() wouldn't take the identity of the caller as an argument; its assumed as an implicit orthagonal piece of information to the call that is not in and of itself part of the call.
Anyway, its my 2-cents. I'll see what I can do.
Thanks for all your input both of you..
0
