Re: Forwarding problem
- From: richard <r.heuft@xxxxxxxxxx>
- Date: Thu, 30 Aug 2007 01:04:02 -0700
First of all thanks for the reply! And second.. I think I wasn't
specific enough about what we exactly need,
I'll try to rephrase what we need to do: The user's smartcard is used
as an access token and will be used (in the near future) by all
doctors, nurses, pharmacists and other healthcare workers for access
to the national messaging infrastructure. The cards are called UZI-
cards (http://www.uziregister.nl/english/). They identify and
authenticate the user on the infrastructure.
Our application has a messaging module which runs on the server B.
This module has to be able to access the infrastructure (server C)
with SSL using client authentication. Basically the client
authentication of the SSL is being used to identify the healthcare
worker behind client A who is accessing the national infrastructure.
Our messaging module of server B has to be able to represent the
client A when initiating a connecting to server C by using the
smartcard. The connection between client A en server B is plain HTTP
and access to the application is being done by an application logon
page with username and password. The smartcard is not (yet) integrated
into the app.
On Aug 29, 7:57 pm, Sylvain <noS...@xxxxxxxx> wrote:
richard wrote on 29/08/2007 15:16:
The problem we're running into is having the clients credentials on
server B for setting up the SSL connection to server C.
may be I miss a (not listed) point but, from my point of view, the
server B shall not need any smartcard *credentials*.
in order to identify the card, it shall use card signature and public
information (health id, digital certificate, ...)
in order to access and then exchange data with C, it should use local
information (its own certificats & keys).
this point assumes that the card pincode is entered by the final
cardholder (thru a local component hosted by the web appl.) and not sent
by the server B or C.
(local card unlocking can also be managed by a doctor card if the one
here described if a patient card.)
We indeed need local input of the pincode on the client on a local
component. The trigger will come from the messaging module on server B
when it is ready to access server C.
Right now we're looking into developing our own CSP or PKCS11
forwarding solution but maybe there's a better option on the Windows
platform we don't know of...yet
CSP and P.11 interface will introduce useless complexity in a web based
scheme, OOH they will not help to carry out credentials (since they
expect them in plain for most of the implementations).
Right know we're focusing on a authentication forwarding solution
which will give us a "virtual" cardreader on server B. It is indeed
complex and might not be the most pratical choice.
Any suggestions on how to best solve this forwarding problem are very
is forwarding strictly required ?
or can you manage plain or protected exchanges between A and B, and
another protected session between B and C ?
We think that forwarding is required because we can only build the
messages on the application server B and need the smartcard from
client A for access. We can manage a plain or protected exchange
between A and B and another session between B and C, but we need the
card for the connection between B and C.
greetings and thanks,
- Re: Forwarding problem
- From: Sylvain
- Re: Forwarding problem
- Prev by Date: cryptdecrypt failed with an error 0x80090020 when using with an ke
- Next by Date: Re: Changing the location of keys and certificates
- Previous by thread: Re: Forwarding problem
- Next by thread: Re: Forwarding problem