| Re: [higgins-dev] [IdAS] authN/authZ issues |
|
I can see where -- for forward compatibility -- we would want to leave this as Object.
I think what we'll do at Novell is define a class or a couple classes which we'll use and we'll try to make them generic enough to be used by a number of CPs. If they are seen as being generally useful enough to more CPs than those written by Novell, maybe we could put them in the repository.
What we need from a high level is probably something like this:
AuthNMaterials class.
- Optionally has a set of AuthNMaterials (this allows us to pass multiple materials in the case of a joined CP)
SASLAuthMaterials extends AuthNMaterials (this allows for multi-part SASL authN to happen)
- String getMechanism(); (mechanisms name from http://www.iana.org/assignments/sasl-mechanisms)
- byte[] exchange(byte[]); (challange/response messages passed here)
I think that gets us pretty much everything we need for our initial providers here. In terms of policy, we'd probably want a way to specify which class must be used and in the case of SASLAuthMaterials, which mechanisms are supported.
We wouldn't mind collaborating with other CP implementors to come up with something that can also serve their needs as well. In the end, what we wish to do is minimize the number of classes the IdAS consumer needs to be aware of.
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 8/9/06 1:57 PM >>> [If you don't want to read the following long message, here's the spoiler: I think that Object is the correct type for the identity parameter in Context.open.] My action item from the last phone meeting was to investigate the authentication and authorization mechanisms for providing Context data to a consuming service (which we will call the "client"). Note that this client is likely to be an ISS or an STS, rather than a human user. The main subject of debate is the "identity" parameter for the Context.open call -- is there a better type than "Object", or can we at least provide guidance to the client about what types are likely to be supported? First, let me emphasize that any code dealing with this issue will be written by the Context Provider (CP), who installs code that implements IContextFactory and IContext interfaces. This means that the IdAS API should be neutral in terms of the authN/authZ mechanisms for gaining access to the Context. Second, I want to identify the four entities involved in delivering attribute data to the client -- the IdASRegistry service, the ContextFactory, the Context, and the DataSource. My expectation is that clients will access the IdASRegistry first, in order to locate a Factory that can service a particular Context. Let's use the term "DataSource" to denote the actual source of attribute information. The job of the Context is to mediate between one or more DataSources and the client. (A DataSource could, in fact, be another Context or another IdAS service, etc., but we'll simply the discussion by assuming that the DataSource is an LDAP directory, file, or database.) As Raj pointed out, there are two scenarios (passthrough and delegate) that describe the authN/authZ relationship between the client and the DataSource. PASSTHROUGH SCENARIO In the "passthrough" scenario, the client is directly authorized to the DataSource. In other words, the client must provide identity credentials to satisfy the policy of the DataSource, and IdAS stays out of the way. The CP's job is to collect this policy information and convey it to the client via Context.getPolicy. Note that different Contexts created by a single Factory may have different policies and different types of credentials required. In the fully dynamic case, the CP will not know ahead of time what type of identity will be required. In other cases, the policy and identity type will be hard-wired into the code. DELEGATE SCENARIO In the "delegate" scenario, the client will be authorized by the IdAS service itself, which will then take responsibility for any authorization needed to access the DataSource. This could be done through a "connector" that knows how to map client credentials to those needed by the DataSource, or it could enlist the aid of an STS to transform client credentials into DataSource credentials. In this case, the policy is provided by the Factory, as it will be the same for every Context. (Should the client use ContextFactory.getPolicy for this? I propose that we instead have Context.getPolicy return the right thing, whether it is imposed by the Factory or the DataSource. The client has one place to go, and it doesn't really care where the policy comes from.) CLIENT-SIDE CODE So what is client code supposed to do, given such flexibility? In current practice, the mechanisms are hard-wired (or configurable), so the client already knows what authN/authZ mechanisms are supported/required. We can presume that this will be the cases in many instances in the near future. In this case it's the client's responsibility to create the right type of object to pass into Context.open. If it passes something that can't be handled, the Context will throw an exception. In a more dynamic case, the client would getPolicy, parse the supported token types, and then create one (probably with the help of an STS). I don't think we want to pass in a javax.security.auth.Subject, because it's JAAS-specific and doesn't always translate to J2EE. I don't think we want to create an interface or abstract class of our own, because all different kinds of tokens could implement this, so there's no real information provided to the client that would help it decide which of these types to instantiate. We could have a Context.getIdentityClass method, but how is that different than getPolicy? The client still needs to know how to instantiate the class properly, and there might be multiple acceptable token types. This leads me to conclude that Object is the best we can do, in order to remain neutral about the underlying mechanisms. _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |