I agree with this, I only think it will be a tough job. I also have a deadline, so I suggest that we split the work.
I may take custom truststore and certificate authentication against LDAP (I already have idea how to do it) but I am open to suggestions. Regards, NGC Sepand M wrote: > > Ok. So from what I've read, we're trying to separate the authorization > part from the SSL socket and let the broker handle it. > This sounds great. It would take more work (not so great since I have > a deadline), but it would be a "proper" solution. > From what I know of JAAS, the subject/principals fully represent > identity. So attaching them to Connection info would be a good idea. > That way, the Transport's job would be to authenticate and the Broker > could handle authorization completely. This would also mean that any > communication system could be used without having to change the Broker > (as long as the Transport can authenticate and create proper > subjet/principals). > > The one thing I will note is that we are changing the ActiveMQ > architecture in that currently, the Brokers are doing both > authentication and authorization (e.g. The Brokers are currently doing > the user name and password validation). > I think, however, that this is necessary because without our change, > there would need to be a new broker for every new, authenticated, > communication system. > > Please tell me if you agree (in which case I'll start looking at > implementation details). > > On 8/2/06, David Jencks <[EMAIL PROTECTED]> wrote: >> I'm confused by the descriptions of this approach, and don't >> understand what is being proposed. I would separate the steps of >> >> 1. validating the client certificate based on the presented >> certificate chain, which in my experience can be done by the standard >> truststore implementation that comes with java, and serves to >> identify the client: this is done during the ssl connection setup >> >> and >> >> 2. deciding if the identified client is someone you want to let into >> the system, which can be done with a JAAS login module that accepts >> either a certificate chain callback handler (probably way overkill), >> the client certificate (possibly overkill, we've already verified the >> validity of the chain), or just the DN. Keeping the DN in LDAP >> should be no problem, perhaps mapped to the principals you want the >> user to have: I think this could be done after the ssl connection is >> set up >> >> and >> >> 3. deciding what permissions the logged in user should get. You >> might want to consider using a JACC like approach: I set up something >> like this for portal permissions in jetspeed2 and suspect something >> similar ought to work for amq. >> >> many thanks >> david jencks >> >> On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote: >> >> > Hi, >> > >> > On 8/2/06, ngcutura <[EMAIL PROTECTED]> wrote: >> >> >> >> Hmmm... It didn't cross my mind but yes, indeed, it is possible. >> >> >> >> We may supply a fake truststore that would return 'true' for any >> >> certificate >> >> submitted for authentication and then perform real authentication >> >> after >> >> connection setup. We would then be able to obtain client >> >> certificate exactly >> >> as you stated. >> >> >> >> If we accept this approach, I see three components to implement: >> >> >> >> 1. Fake truststore >> >> 2. CertificateLoginModule (against LDAP) >> >> 3. Tweak connection setup to ask for peer certificates. >> >> >> >> In 3. we actually need some kind of policy reagarding authenitcation. >> >> Although SSL connection is established, a client may still supply >> >> username/password meaning that it should be used for login. I >> >> guess that >> >> obtaining client certificate from SSL session should be the last >> >> option. >> >> >> >> In 'Certificate login' thread I described another approach: >> >> >> >> We may use SSL without client authentication but find a way to export >> >> certificate to a String (on client side) and then supply that >> >> string as >> >> 'username' in createConnection(). On server side, the String would be >> >> converted back to certificate and authenticated. With this >> >> approach, we need >> >> to agree on the string format and conversion discipline and then only >> >> another JAAS login module is required (that would actually perform >> >> coversion >> >> from String to Certificate and authenticate). Thus no change is >> >> required in >> >> existing code. We may even add another non-portable >> >> createConnection(Certificate, brokerURL) that would convert >> >> Certificate to >> >> String and invoke createConnection(username, password, brokerURL). >> >> So, the >> >> necessary modules to implement would be: >> >> >> >> 1. Utility to convert Certificate to a string and back. >> >> 1a. (optional) createConnection(Certificate, brokerURL) method and >> >> ActiveMQConnection(Certifcate, brokerURL) constructor that perform >> >> conversion from Certificate to String using utility in #1 and invoke >> >> appropriate existing meothods/constructors. >> > >> > This sounds fine to me too. I would use the DN as the userId and >> > encode the certificate as a string for the password and add a >> > ActiveMQConnectionFactory.setCertificate( Certificate ) and have that >> > set userid/password. >> > >> >> 2. JAAS login module that accepts username (and blank password; or >> >> whatever >> >> convenient) converts it back to Certificate using utility in #1 and >> >> authenticates it. >> >> >> > >> > Yep, sounds good to me. BTW, how easy is it to get Certificate >> > instance? Is this susceptible to spoofing? >> > >> >> >> >> I didn't like this approach at first but now it seems the >> >> quickiest (and the >> >> dirtiest) solution. Actually, it is developing a new protocol on >> >> exisitng >> >> facilities. >> >> >> >> Any thoughts? >> >> >> >> Regards, >> >> NGC >> >> >> >> >> >> Hiram Chirino wrote: >> >> > >> >> > I guess I don't understand what you mean by #2 but that could be >> >> due >> >> > to my ignorance of the SSL socket stuff. So perhaps you can >> >> help me >> >> > understand what happens there... >> >> > >> >> > Lets assume we setup the ssl stuff to use 'need client auth'. >> >> Could >> >> > we setup a truststore implementation that accepts any client >> >> > certificate or would this be a problem? >> >> > >> >> > Can you later get use the SSLScoket.getSession >> >> ().getPeerCertificates() >> >> > when the ConnectionInfo command comes in and attach those >> >> certificates >> >> > to the command? >> >> > >> >> > Could that Certificate[] later be used against an LDAP JAAS module? >> >> > >> >> > Regards, >> >> > Hiram >> >> > >> >> > On 8/2/06, ngcutura <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> >> Hiram Chirino wrote: >> >> >> > >> >> >> > On 8/2/06, ngcutura <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> I started another thread, unaware of this one, with the same >> >> aim. >> >> >> >> >> >> >> >> http://www.nabble.com/forum/ViewPost.jtp?post=5583011&framed=y >> >> >> >> >> >> >> >> So please allow me to share my views on this. >> >> >> >> >> >> >> >> If we are going to use SSL and SSL's built in client >> >> authentication, >> >> >> then >> >> >> >> I >> >> >> >> would use JAAS to authenticate the user via certificate. I >> >> would use >> >> >> LDAP >> >> >> >> to >> >> >> >> store and verify certificates and I guess It would be fairly >> >> easy to >> >> >> >> implement. There is already LDAPLoginModule and I implemented >> >> >> >> LDAPAuthorizationMap - cerificates should not be much harder. >> >> >> >> >> >> >> > >> >> >> > Sounds good! >> >> >> > >> >> >> >> The outcome of successful SSL client authentication should be >> >> >> >> authenticated >> >> >> >> Subject with all Princiapls set. This I woud put into >> >> ConnectionInfo - >> >> >> no >> >> >> >> need for DN or username. When AMQ has authenticated Subject, >> >> it can >> >> >> >> perform >> >> >> >> authorization in any of the existing ways. That is, we can >> >> safely >> >> >> >> separate >> >> >> >> authentication from authorization modules as long as AMQ >> >> gets Subject >> >> >> >> from >> >> >> >> the authentication process. >> >> >> >> >> >> >> > >> >> >> > agreed. >> >> >> > >> >> >> >> What I miss here is the point of Subject creation. If we >> >> totally rely >> >> >> on >> >> >> >> SSL >> >> >> >> for authentication we actually need an implementation of >> >> truststore >> >> >> >> (keystore with trust manager) that would verify client >> >> certificate and >> >> >> >> create login Subject. However, as this process is totally >> >> hidden from >> >> >> AMQ >> >> >> >> (I >> >> >> >> think that truststore and ConnectionInfo instance are >> >> unaware of each >> >> >> >> other), we would need another store (directory) to >> >> temporarrily save >> >> >> >> Subject >> >> >> >> and make it avaliable to AMQ once the connection is created. >> >> Or, if >> >> >> there >> >> >> >> is >> >> >> >> a way for truststore to interact with ConectionInfo >> >> instance, this >> >> >> >> problem >> >> >> >> is solved. >> >> >> > >> >> >> > I'm not familiar with the SSL details to get this done, so I >> >> may be >> >> >> > talking alot of BS here.... But it sounds like your saying >> >> that we >> >> >> > need associate our keystore with the SSL layer. But we want >> >> to store >> >> >> > our certs in LDAP. And right now those two layers would >> >> communicate >> >> >> > via a ConnectionInfo object. So I would say that in this >> >> case the >> >> >> > user is authenticating/logging in earlier than in normal >> >> cases. since >> >> >> > he is authentcating at connection setup time, I think you >> >> would need >> >> >> > to do the JAAS log in when the connection is estbalished. >> >> And attach >> >> >> > the JAAS subject to the ConnectionInfo. >> >> >> > >> >> >> > ---REPLY BEGINS--- >> >> >> > (I don't know how to produce '>' when quoting using the Web >> >> interface >> >> >> on >> >> >> > Nabble.) >> >> >> > >> >> >> > Your understanding is compatible with mine. :-) What I >> >> undestood from >> >> >> JSSE >> >> >> > is that it is actually a component that you may configure >> >> independantly >> >> >> of >> >> >> > the rest of the application. You specify a factory and a >> >> truststore and >> >> >> > connection is returned. SSL server and client authentication >> >> based on >> >> >> > certificates is configurable but totally hidden from the >> >> application. >> >> >> What >> >> >> > we can do to interfere is implement SSLSocketFactory and >> >> implement >> >> >> > truststore. >> >> >> > >> >> >> > Now, if we bypass client authentication during SSL handshake >> >> and leave >> >> >> it >> >> >> > until the connection is established, the question is how we >> >> obtain >> >> >> client >> >> >> > ceritifcate. If the client is not required to authenticate >> >> during SSL >> >> >> > handshake, it will not send its certificate to the server and >> >> we lose >> >> >> > possibility to perform client certificate authentication. >> >> Thus we need >> >> >> to >> >> >> > set 'need client auth' or 'want client auth' property to the >> >> server >> >> >> SSL >> >> >> > socket factory. (I saw a discussion thread where this was >> >> resolved in >> >> >> > AMQ.) In both cases, I believe (although I am not sure) client >> >> >> > ceritificate authentication wil be attempted. In case of 'need' >> >> >> > unsuccessful authentication will disconnect client while in >> >> the case of >> >> >> > 'want' connection will be created. Maybe this can be used in >> >> our case >> >> >> but >> >> >> > I am not sure how 'want' case is handled exactly. If there >> >> are any >> >> >> > restrictions imposed on such a connection, we lose the case. >> >> >> > >> >> >> > Back to the normal SSL handshake: if we implement our own >> >> truststore >> >> >> (we >> >> >> > need to) and our own SSL socket factory (we may) and create >> >> >> ConnectionInfo >> >> >> > instance before the actual connection (I am now talking >> >> unaware of the >> >> >> > actual code in AMQ - I have not studied it yet) maybe there >> >> would be a >> >> >> way >> >> >> > to pass ConnectionInfo instance to the custom SSL socket >> >> factory which >> >> >> > would then pass it to the custom truststore and we are in >> >> business. >> >> >> > >> >> >> > Some gymnastics, admitedly. :-) >> >> >> > >> >> >> > What we need to resolve is this: >> >> >> > >> >> >> > 1. In case of 'wantClientAuth' what are the consequences of >> >> >> unsuccessful >> >> >> > client authentication? Is the connection as good as >> >> authenticated or >> >> >> are >> >> >> > there any restrictions? >> >> >> > >> >> >> > 2. Is there a way to pass ConnectionInfo instance via factory >> >> to the >> >> >> > truststore as suggested? >> >> >> > >> >> >> > Answers to the above questions would give us a way to go. >> >> Still, if >> >> >> there >> >> >> > would be a positive answer to the question 2. I would go that >> >> way >> >> >> > regardless of the 1. Therefore, I volounteer to resolve 2. :-) >> >> >> > >> >> >> > Any ideas? >> >> >> > >> >> >> > Regards, >> >> >> > NGC >> >> >> > ---REPLY ENDS--- >> >> >> >> >> >> >> >> This approach requires implementation of >> >> CertificateLoginModule (JAAS) >> >> >> >> and >> >> >> >> custom truststore that would use this login module plus some >> >> temporary >> >> >> >> map. >> >> >> >> >> >> >> >> What do you thik about this? >> >> >> >> >> >> >> >> Regards, >> >> >> >> NGC >> >> >> >> >> >> >> >> >> >> >> >> Hiram Chirino wrote: >> >> >> >> > >> >> >> >> > On 8/1/06, Sepand M <[EMAIL PROTECTED]> wrote: >> >> >> >> >> Hi all, >> >> >> >> >> >> >> >> >> >> So far I've mainly been reading ActiveMQ and making >> >> design docs. >> >> >> >> >> Here's what I've got: >> >> >> >> >> >> >> >> >> >> For authorization, my current plan is to just have the >> >> client's DN >> >> >> >> >> replace the user name field in the ConnectionInfo class >> >> (how this >> >> >> is >> >> >> >> >> done is explained below). I want to do this because I >> >> don't know >> >> >> much >> >> >> >> >> about JAAS and I'm trying to avoid writing classes to >> >> authorize >> >> >> based >> >> >> >> >> on DNs. If you guys know this stuff (and you probably >> >> do), we could >> >> >> >> >> change this easily enough. >> >> >> >> >> >> >> >> >> >> Here's the rest of my design: >> >> >> >> >> >> >> >> >> >> I want to modify SslTransportFactory to use a specific >> >> SslContext >> >> >> >> >> object and allow client's access to its init method so >> >> that they >> >> >> can >> >> >> >> >> set their own key and trust managers. I also want to >> >> create new >> >> >> >> >> SslTransport and SslTransportServer classes. SslTransport >> >> will be >> >> >> >> >> derived from TcpTransport. Its main task will be to >> >> replace the >> >> >> user >> >> >> >> >> name field of ConnectionInfo commands with its socket's >> >> DN (this >> >> >> could >> >> >> >> >> be changed easily to attach the entire certificate to >> >> >> ConnectionInfo >> >> >> >> >> as a new generic field). SslTransport will also make sure >> >> that it >> >> >> uses >> >> >> >> >> SslSocketFactory's. SslTransportServer will only be there >> >> to make >> >> >> sure >> >> >> >> >> SslSocketFactory's are used. >> >> >> >> >> >> >> >> >> >> For my current design that about does it. The proper >> >> Brokers and >> >> >> >> >> plugins (JaasAuthenticationBroker and >> >> AuthorizationPlugin) would >> >> >> have >> >> >> >> >> to be used and the configuration files would need to use >> >> the DN as >> >> >> the >> >> >> >> >> username. >> >> >> >> >> >> >> >> >> >> I'm not sure about this, but I think if we were to attach >> >> the >> >> >> complete >> >> >> >> >> certificate and try to do things "properly" we'd need a new >> >> >> >> >> CertificateAuthenticationBroker and a way for JAAS to >> >> authenticate >> >> >> >> >> that certificate (I'm new to JAAS so I don't know how >> >> easy/hard >> >> >> this >> >> >> >> >> would be). >> >> >> >> >> >> >> >> >> > >> >> >> >> > Sounds spot on! The JAAS part would totally depend on how >> >> the JAAS >> >> >> >> > module that authenticates against a certificate expects to >> >> receive >> >> >> the >> >> >> >> > certificate. Right now our current JAAS login only uses >> >> >> >> > userid/password, that would need to change for a cert. >> >> Anybody know >> >> >> >> > where we can get a JAAS module that authenticates >> >> certificates? >> >> >> >> > >> >> >> >> > Regards, >> >> >> >> > Hiram >> >> >> >> > >> >> >> >> >> Any thoughts? >> >> >> >> >> - Sepand >> >> >> >> >> >> >> >> >> >> On 8/1/06, James Strachan <[EMAIL PROTECTED]> wrote: >> >> >> >> >> > On 8/1/06, ngcutura <[EMAIL PROTECTED]> wrote: >> >> >> >> >> > > >> >> >> >> >> > > My JIRA username is 'ngcutura' and I'll be glad to >> >> assign LDAP >> >> >> >> >> Authorization >> >> >> >> >> > > issue to myself. >> >> >> >> >> > >> >> >> >> >> > Great! You're all set now with JIRA karma >> >> >> >> >> > >> >> >> >> >> > > I also take this opportunity to remind you of my code >> >> >> >> >> > > waiting for your review. :-) >> >> >> >> >> > >> >> >> >> >> > Thanks for the reminder - will try get there soon :) >> >> >> >> >> > >> >> >> >> >> > > I wouldn't mind creating and assigning certificate >> >> login but as >> >> >> >> >> Sepand was >> >> >> >> >> > > the first to raise it I'd wait for him (a while). >> >> >> >> >> > >> >> >> >> >> > Coolio >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > >> >> >> >> >> > James >> >> >> >> >> > ------- >> >> >> >> >> > http://radio.weblogs.com/0112098/ >> >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Regards, >> >> >> >> > Hiram >> >> >> >> > >> >> >> >> > Blog: http://hiramchirino.com >> >> >> >> > >> >> >> >> > >> >> >> >> -- >> >> >> >> View this message in context: >> >> >> >> >> >> >> http://www.nabble.com/Creating-a-secure-connection-system-and- >> >> using-JMSXUserID-support-tf1956575.html#a5612820 >> >> >> >> Sent from the ActiveMQ - Dev forum at Nabble.com. >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Regards, >> >> >> > Hiram >> >> >> > >> >> >> > Blog: http://hiramchirino.com >> >> >> > >> >> >> > >> >> >> -- >> >> >> View this message in context: >> >> >> http://www.nabble.com/Creating-a-secure-connection-system-and- >> >> using-JMSXUserID-support-tf1956575.html#a5617424 >> >> >> Sent from the ActiveMQ - Dev forum at Nabble.com. >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > Regards, >> >> > Hiram >> >> > >> >> > Blog: http://hiramchirino.com >> >> > >> >> > >> >> -- >> >> View this message in context: http://www.nabble.com/Creating-a- >> >> secure-connection-system-and-using-JMSXUserID-support- >> >> tf1956575.html#a5619195 >> >> Sent from the ActiveMQ - Dev forum at Nabble.com. >> >> >> >> >> > >> > >> > -- >> > Regards, >> > Hiram >> > >> > Blog: http://hiramchirino.com >> >> > > -- View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5630156 Sent from the ActiveMQ - Dev forum at Nabble.com.
