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_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>