Centralized Authorization

[icyrus]

Does anyone here have any experience with a centralized authorization system?

Or any thoughts on such a system?

 

[greggpb]

in what context? Using windows I normally use the NT security.

 

[Nod]

LDAP works quite well. Most systems support LDAP as backend, and there are a whole lot of different servers available (openldap, sun directory server, etc).

 

[Veroland]

First of all I would assume you mean Single Sign on, which in iteself has lots of different meanings and implementations, you will have to give some more info

 

[icyrus]

in what context? Using windows I normally use the NT security.

UNIX and open source software are my preference.

Context - multiple disparate services that use the common infrastructure for authorization of client requests.

LDAP works quite well. Most systems support LDAP as backend, and there are a whole lot of different servers available (openldap, sun directory server, etc).

OpenLDAP does form part of my solution as a directory service, but how were you thinking of its role in authorization specifically?

 

[icyrus]

First of all I would assume you mean Single Sign on, which in iteself has lots of different meanings and implementations, you will have to give some more info

Not SSO. Well not really. Kerberos implementations are likely to form the authentication part of the equation so that will take care of SSO.

So, given an authenticated client request I need a general, flexible authorization infrastructure with central policy controls.

The complexity of authorization and per service requirements normally means that such a thing is impossible, but I thought it would be interesting to get others ideas and thoughts.

 

[Veroland]

Not SSO. Well not really. Kerberos implementations are likely to form the authentication part of the equation so that will take care of SSO.

So, given an authenticated client request I need a general, flexible authorization infrastructure with central policy controls.

The complexity of authorization and per service requirements normally means that such a thing is impossible, but I thought it would be interesting to get others ideas and thoughts.

Yet again you are vague, sorry, I am a back end person, do you need to pass on your authorisation tokens to other systems and they have to accpect / authenticate it before transactions can continio?

Maybe you need to share what technoilogy infrastructure you are using as they all handle it in different ways

EDIT: BTW, this is one of the issues I am currently facing

 

[icyrus]

Yet again you are vague, sorry, I am a back end person, do you need to pass on your authorisation tokens to other systems and they have to accpect / authenticate it before transactions can continio?

Maybe you need to share what technoilogy infrastructure you are using as they all handle it in different ways

EDIT: BTW, this is one of the issues I am currently facing

Sorry, I am vague because it's more theoretical than practical at this stage.

For instance:

Service A accepts a kerberos ticket from client B. Client B is now authenticated to service A through the ticket.

B then requests a certain resource from A. A now needs to determine if client B is authorized to access this resource.

How the service determines if the request should be authorized or not is what I am currently interested in. Specifically shared policy and ACL infrastructure that could be used by multiple services in the realm for the same set of clients.

 

[Veroland]

B then requests a certain resource from A. A now needs to determine if client B is authorized to access this resource.

Ok, we are talking authorization and not authentication. Are you going to use a web technology?

 

[icyrus]

Ok, we are talking authorization and not authentication.

Yeah.

Are you going to use a web technology?

An interesting question. The services would most likely be based on HTTP. How does it affect the situation though?

 

[Veroland]

An interesting question. The services would most likely be based on HTTP. How does it affect the situation though?

We run all our requests through a HTTPS proxy that does the encrypting / decrypting for us and we then delegate the session context to the back end systems which then verify the context ass well.

As for authorization we have a filter in place that checks every (https) request to see if the user that are making the request is actually allowed to access that specific function.

 

[icyrus]

As for authorization we have a filter in place that checks every (https) request to see if the user that are making the request is actually allowed to access that specific function.

Across multiple services I assume?

How does the filter make the authorization decision? Are you using a custom-built policy engine?

 

[Veroland]

Yep we built our own, we are now looking at maybe using something like the spring authorization engine.

And yes, multiple services (and multiple back end systems), thats why I mentioned the authentication piece.

 

[icyrus]

Yep we built our own, we are now looking at maybe using something like the spring authorization engine.

And yes, multiple services (and multiple back end systems), thats why I mentioned the authentication piece.

Interesting. Thanks for the info.

What would you say the drawbacks & benefits of your current setup are?

 

[Veroland]

We have a need for tight security and that in itself has a lot of drawbacks. Some advantages we do have is that we can control access in a centralized place. It does feel like it is a constant fight against fraud at some times though. Does not matter what you put in place, some w@nker will somewhere will find a loophole