Java authentication client for Windows
We are looking into the option of building a Java replacement client for Windows GINA, so that we can replace the RSA client (currently installed on MANY smartcard equipped workstations in the scope of our project). I looked into SSPI but can't find anything useful. Any guidelines and/or suggestions?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Reading through the lines here - if you are just trying to get rid of an existing Gina, if that is what you meant by 'replace the RSA client ', then you can try using certificate logon. Some smart card (SC) companies use a fake method wherein you still actually log in using username/password but those are stored encrypted and the cert decrypts that info and then passes it to their bloated replacement gina - this is how entrust does things, at least up until 2-3 years ago and I can't imagine that they bothered to change it.
That being said, many SC vendors offer actual certificate logon and may also include an option to have user/pass instead while still getting to use the SC logon options in GPO. Cert logon will require their middleware to interpret their card data in most cases and add their ATR value to the registry so windows can recognize what card type it is talking to, but the GINA would be optional in most cases. If your RSA is for using the numeric keyfob things, then there's no real way around that besides replacing them.
I guess what I am trying to say is that you could try doing normal certificate logon and getting rid of the 3rd party gina and just working with the standard msgina.dll from MS.
If I'm off and you are looking to add functionality - you can have multiple stub gina's if you want to extend functionality somehow but their gina is in the way. This gets tricky to determine who's stub should attach to whoms. Usually it would be something like VPN - SC - Gina so that VPN stub would intercept the logon and verify the user off the VPN database or whatever, then make the auth request to the gina for the windows stuff, the SC stub would intercept and get the SC data from user's card and get the cert and submit that to the gina, then the actual gina would pass the cert logon through kerberos and get permission to logon which it pushes back to the client - the SC gina sees it long enough to not error out and passes to the VPN which uses that to grant VPN authorization and then pass to user the right to log on remotely. However, if the SC contains data that the VPN will use beyond Windows info, then maybe the chain would have to be different so that SC is first passing to VPN to GINA.
If you are trying to chain gina stubs, there is usually an order - working with the manufacturer of the other one will usually be the best route to go. From a consumer standpoint - call tech support for both companies for best results and if they disagree make them test it out in their lab, not your network. There is usually a custom registry key that the vendors will make to chain their gina in - this custom name will then specify who they pass to next - there is no generic for this unless it is a full replacement under GinaDLL (this may or may not show up in the registry, but is used for full gina replacements like entrust and citrix - hence entrust and citrix do not play nice together) - default is msgina.dll for this value for microsoft's gina.
Okay my coffee is wearing out.
That being said, many SC vendors offer actual certificate logon and may also include an option to have user/pass instead while still getting to use the SC logon options in GPO. Cert logon will require their middleware to interpret their card data in most cases and add their ATR value to the registry so windows can recognize what card type it is talking to, but the GINA would be optional in most cases. If your RSA is for using the numeric keyfob things, then there's no real way around that besides replacing them.
I guess what I am trying to say is that you could try doing normal certificate logon and getting rid of the 3rd party gina and just working with the standard msgina.dll from MS.
If I'm off and you are looking to add functionality - you can have multiple stub gina's if you want to extend functionality somehow but their gina is in the way. This gets tricky to determine who's stub should attach to whoms. Usually it would be something like VPN - SC - Gina so that VPN stub would intercept the logon and verify the user off the VPN database or whatever, then make the auth request to the gina for the windows stuff, the SC stub would intercept and get the SC data from user's card and get the cert and submit that to the gina, then the actual gina would pass the cert logon through kerberos and get permission to logon which it pushes back to the client - the SC gina sees it long enough to not error out and passes to the VPN which uses that to grant VPN authorization and then pass to user the right to log on remotely. However, if the SC contains data that the VPN will use beyond Windows info, then maybe the chain would have to be different so that SC is first passing to VPN to GINA.
If you are trying to chain gina stubs, there is usually an order - working with the manufacturer of the other one will usually be the best route to go. From a consumer standpoint - call tech support for both companies for best results and if they disagree make them test it out in their lab, not your network. There is usually a custom registry key that the vendors will make to chain their gina in - this custom name will then specify who they pass to next - there is no generic for this unless it is a full replacement under GinaDLL (this may or may not show up in the registry, but is used for full gina replacements like entrust and citrix - hence entrust and citrix do not play nice together) - default is msgina.dll for this value for microsoft's gina.
Okay my coffee is wearing out.
ASKER
Thanks...