Date: Mon, 21 May 2007 09:56:35 +0300
To understand the way of the used certificate authorization I use MS IE where I open the following forms:
[Tools][Internet Options...][Content][Certificates...]
1. Internet Options.jpg
2. Certificates.jpg
3. Certificate.jpg
4. Certificate-EnhancedKeyUsage.jpg
There are 3 certificates which are used for Authentication. The first 2 are putted in to the SmartCard from the bank together with smart card initialization. The 3rd certificate is putted in to the SmartCard from MS Interenet Explorer during user registration process. This is very interesting and useful option which is good the be realized in JavaEE also.
I found the following additional information for this kind of authentication:
1. Requirements for Domain Controller Certificates from a Third-Party CA (http://support.microsoft.com/kb/291010)
2. Some security methods (like TLS, TTLS, or PEAP) use digital certificates assigned to each user for authentication (http://docs.hp.com/en/T1428-90056/ch11s05.html).
server configiration in Glassfish is done in domain.xml. Is that what you mean by the server XML configuration file?Yes, this is OK.
Miroslav, sorry to keep saying this, but until we identify exactly the authentication protocol that you want to integrate in Glassfish, we are mostly just guessing whether it is a two-factor mechanism.Is the above information enough for you?
Best Regards,
Miroslav Nachev
Ron Monzillo wrote:
Miroslav Nachev wrote:
Dear Ron,understood
First I would like to clear my point:
1. This two-factor or two-pass authentication mechanism MUST be available for both Web Client and Swing Client based applications.
2. In my opinion the configuration how many passes and their order have to be described in server XML configuration file.
3. For which type of client (Web or Swing) which kind of authentication to be used have to be specified in XML files also.
4. Which of the available Client side features to be enabled to be described in the XML file.
server configiration in Glassfish is done in domain.xml. Is that what you mean by the server XML configuration file?
Glassfish does provide a facility for configuring new security mechanism providers (i.e jsr 196 Server Authentication Modules - SAMs ) in domain.xml.
the details of the implementation of the protocol, would be encapsulated in the implementation of the SAM.
can you identify the pluggin that you install in Mozilla Firefox.
The interesting is that I am not installed any plugin neither Mozilla Firefox, neither MS Internet Explorer. That's why I think that this is a regular standartized way for such kind of authentication. If it is true, then I have to implement only the server part of the protocol and the Swing Client. The Web client is standardized.
I would like the Swing client to use the same Server implementation which is used for Web client and is integrated in Mozilla Firefox and MS Internet Explorer. So, the Swing client have to copy the algorithm from Mozilla Firefox.
yes, the server side SAM functionality should be constaint independent of the client type, and I agree that the swing client will need to emulate the browser.
As suggested by one of my colleagues, you may be using a two-factor authentication mechanism.
Is this two-factor authentication mechanism realized in Glassfish? Where can I read more for that?
no, there are several such mechanisms, but Glassfish does not ship with a SAM for any two factor mechanism.
Miroslav, sorry to keep saying this, but until we identify exactly the authentication protocol that you want to integrate in Glassfish, we are mostly just guessing whether it is a two-factor mechanism.
The fact that you did not need to upgrade your browser, makes me wonder if you are using a mechanism that comes integrated in firefox, or whether what you are seeking to emulate is a case of a username/passowrd based application acting as a portal to an app protected by client certificate authentication.
if you are familar with the "about:config" facility fo firefox, you should be able to see the security facilities integrated your firefox browser.
sorry, for asking so many questions, let me try to summarize.
we need to know the authentication protocol that you want to integrate in glassfish, and then someone will need to write a SAM and integrate it in glassfish (via the glassfish/jsr 196 SAM configuration facility).
Ron
Best Regards,
Miroslav Nachev
Ron Monzillo wrote:
Miroslav Nachev wrote:
I would like to repeat the same logic like Web browser because there are too many applications working with this logic. Of course the Swing client will work directly with EJB3 instead with Web tier. I would like to do that because the bank branch use this and they believe (trust) to this technology. Also this technology is good and it is not necessary to create new one just to be different from Web technology. Why to do something new in case that we can use the idea which is good and to implement to Swing?
Miroslav,
thanks for the additional info. The Glassfish EJB tier is invoked over iiop, so I believe you will need to replace the portable interceptors in both the client and servlet containers, in order to bind a new authentication mechanism within the iiop messaging layer.
We expect to develop a profile of jsr 196 for use in the iiop messageing layer; but that has not been done yet.
if it is the case that you want the client to send a cryptographic authenticator in the request message, can you provide a little more detail as to the form of the authenticator? will it be added as added as a header that will be available to the server via the HttpServletRequest api, and if so, what will be its format.
I am not familiar with the exact technology because the used one in Bulgaria is Microsoft based, but I am familiar with Java Security, Java XML Security and other security standards like XAdES, so I can use this. Also, the technology is common I think because this works with MS Internet Explorer and Mozilla Firefox with the same way. After the
can you identify the pluggin that you install in Mozilla Firefox.
I presume that you want to implement a specific authentication dialog; in which case we need to identify the format of the security tokens/authenticators that are exchanged.
Username/Password pass successfully, a new message box (Dialog) is shown where I am prompted to enter the PIN code for the SmartCard. Then if on the SmartCard are located more than one certificates I have new Dialog where are listed just these certificates which are for the current bank. I choose the right one and then the Certificate authorization pass successfully. Please find the attached snapshots:
1. Login-stage-1-username-password.jpg
2. Login-stage-2-certificate-selection.jpg
3. Login-stage-3-certificate-authorization.jpg
Please note, that the request which is coming from the Server is related with the used username. That's why I have to choose this Certificate Principal which correspond to the login username.
As suggested by one of my colleagues, you may be using a two-factor authentication mechanism. Based on what you wrote above, its sounds like you want to develop a client that conforms to an existing mechanism, and that you also want to integrate support for the server-side of the mechanism in Glassfish.
If this is correct, you will need to identify the specific security mechanism, so that we can see how the authenticators must be formed by the client and how the server must format challenges and validate authenticators.
Ron
ps; based on your answers, I am presuming that you use case is NOT one where the user contacts a portal which requires username/password based authentication; and is redirected by the portal to an app which requires client-cert authentication.
If you can show me a sequence diagram of the authentication dialog, I shoulkd be able to map your protocol onto a ServerAuthModule.
Can you provide a reference to the "banking authorization process" you are using?
No
Client
Direction
Server
1
Create SSL
=>
2
<=
Request for Username/Password
3
Answer: Send Username and Password
=>
4
<=
If success, send request for the Certificate Authorization using Subject/Issuer (X509Principal) and other (I don't know what exactly if any)
5
Looking for Certificate stores (PKCS#11, PKCS#12, JKS, etc.)
6
If there are more than one certificates with this issuer (bank) then show the Dialog for choice (we can use Subject instead Issuer and in this case we will know exactly which is the needed certificate)
7
The Client is asking for the password (PIN) of the Certificate Store
8
Some MD/Sign is calculated using the Private key
9
The MD/Sign is send to the Server
=>
10
The Server check this MD/Sign using Public key.
Regards,
Miro.
Ron Monzillo wrote:
Miroslav Nachev wrote:
Dear Ron,Miroslav,
I mean this:
a. the user agent (which appears to be a browser) is using the private key corresponding to its certificate to produce a crytographic authenticator for verification by the server, or
In my case I would like the web browser user agent to be replaced from Swing user agent. I think that this will not be a problem. The certificate with related private and public keys are on the client side. The server side keep only the certificate and public key.
it sounds like, swing user agent will exchange a username and passord over ssl, and then it will use a private key to sign something which will be sent to the server (over the ssl protected transport), and the server will use the corresponding public key to validate that the corresponding privaye key was known to the user agent.
I can accept that a swing user agent could do the above, but this seems like more than could be expected from a typical browser, and it sounds like you are trying to write a swing client that does what would otherwise be done by a browser, and that you want to be able to extend the server side to support such clients.
if it is the case that you want the client to send a cryptographic authenticator in the request message, can you provide a little more detail as to the form of the authenticator? will it be added as added as a header that will be available to the server via the HttpServletRequest api, and if so, what will be its format.
I still am not sure I completely understand your client and the type of messages that it will send, but i think you will be able to perform the server-side processing by writing a ServerAuthModule as described in chapter 3 of the jsr 196 specification.
If you can show me a sequence diagram of the authentication dialog, I shoulkd be able to map your protocol onto a ServerAuthModule.
Can you provide a reference to the "banking authorization process" you are using?
Ron
Best Regards,
Miroslav Nachev
Ron Monzillo wrote:
Miroslav Nachev wrote:
Hi Ron,
I don't fully understand your use model (especially the relationship between 4.3 and the username/password mechanism
In Bulgaria and in tested European Internet banking the authorization process is in 2 stages:
1. SSL Username/Password
Miroslav,
I still don't understand.
I presume step 1 is BASIC Auth over SSL or (something equivalent).
2. Certificate authorization where the certificate is generated from the bank in most cases.
what exactly is step 2. For me to understand, it would help to show the msg flows, but maybe you can just answer the follwoing.
By "certificatate authorization" do you mean
a. the user agent (which appears to be a browser) is using the private key corresponding to its certificate to produce a crytographic authenticator for verification by the server, or
b. the user-agent/browser is verifying the certificate of the server, to ensure that the browser is communicating (i.e. exchanging its password) with the proper service, or
c. something else
thanks,
Ron
ps: in jsse, (b) can be implemented using a hostname verifier; but in this case, the verifier runs just after the ssl handshake is complete, and before the username and password is exchanged.
If the Username/Password is not passed, then the 2nd authorization (certificate) is not started.
If the Username/Password is passed, then the certificate authorization is started. If and only the certificate authorization is passed you can continue with Internet Banking. At the moment Web certificate authorization use the default certificate store in the active web browser like Mozilla or Internet explorer. In my case I use PKCS#11 (SmartCard) to store the certificates. Before I am used PKCS#12 or integrated.
Regards,
Miro.
Ron Monzillo wrote:
Miroslav,
I don't fully understand your use model (especially the relationship between 4.3 and the username/password mechanism, but that may be immaterial. Let me try to focus on your first question. Glassfish is the reference implementation for jsr 196, which is the java authentication spi for containers. The spec is in proposed final draft, and will soon be submitted for finalization ballot.
Chapter 3 of the spec defines how to use the spi to add support for a new authentication mechanism to a compatible servlet container.
The spec does not define interfaces for items 5 and 6 in your list; however, it may be best to handle both by directing the user to interact with an authentication service on which the application/servlet container relies (such as an openSSO identity provider).
The 196 spec can be found at:
http://jcp.org/en/jsr/detail?id=196
Ron
Miroslav Nachev wrote:
Hi,
I am going to design and develop new SwingX based Login dialog (see the attached images), because the existing one which is in the GlassFish is not enough. I am not sure but I think that the new functionality will require new Server part.
*Can you give me some suggestions how to do the server part?*
The functionality is as follow:
1. Username/Password login;
2. After unsuccessful authorization the Error message dialog will be shown (wrong username or password).
3. After Cancel or Close nothing will happen
4. After successful authorization:
4.1. the username and language will be saved in the user local profile to be used on the next login in ComboBox;
4.2. if remember password is checked the password will be stored in the user local folder in JKS format;
4.3. if on the Server part is checked Certificate authorization which is required for the Bank authentications the Certificate authentication will be started.
5. If the user is new, then can be used button for new user registration in "Options" expansion.
6. If the user can not remember the password, the "forgot your password" can be used from "Options" expansion.
Best Regards,
Miroslav Nachev
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
(image/jpeg attachment: Internet_Options.jpg)
(image/jpeg attachment: Certificates.jpg)
(image/jpeg attachment: Certificate.jpg)
(image/jpeg attachment: Certificate-EnhancedKeyUsage.jpg)