Excellent! Glad things worked out. Don't need to thank me - the actual work was done by colleagues in identifying the problem - I just did the communication work. Have a good weekend.
Desmond, Here is the problem. Of the 332 entries in the FIDO Alliance Metadata Services (MDS), the entry corresponding to the attestation certificate of OneSpan's authenticator is the ONLY one that has an invalid character in it: AAGUID: 30b5035e-d297-4ff1-b00b-addc96ba6a98 contains : YES "\tMIICojCCAkigAwIBAgIUVn2bWvs0Kl27jgwu1cLl8PxDo34wCgYIKoZIzj0EAwIwgacxCzAJBgNVBAYTAkJFMRAwDgYDVQQIDAdCcmFiYW50MRgwFgYDVQQHDA9TdHJvbWJlZWstQmV2ZXIxEDAOBgNVBAoMB09uZVNwYW4xIjAgBgNVBAsMGUF1dGhlbnRpY2F0b3IgQXR0ZXN0YXRpb24xDDAKBgNVBAMMA0NYMTEoMCYGCSqGSIb3DQEJARYZam9oYW4udmVycmVwdEBvbmVzcGFuLmNvbTAeFw0yMjEyMDIxMTQ1MjhaFw0zMjExMjkxMTQ1MjhaMIGnMQswCQYDVQQGEwJCRTEQMA4GA1UECAwHQnJhYmFudDEYMBYGA1UEBwwPU3Ryb21iZWVrLUJldmVyMRAwDgYDVQQKDAdPbmVTcGFuMSIwIAYDVQQLDBlBdXRoZW50aWNhdG9yIEF0dGVzdGF0aW9uMQwwCgYDVQQDDANDWDExKDAmBgkqhkiG9w0BCQEWGWpvaGFuLnZlcnJlcHRAb25lc3Bhbi5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARfH/AnC2HAV2B44SbfoSMegBQ2Uxa+SlYhp8YGeEolvaMSTTSMVEg2qalHPCwc20WftsHGWIDPauB4ny77Rfqyo1AwTjAdBgNVHQ4EFgQUwD45b6V2a+CxGFcsjjEmBmt/RUswHwYDVR0jBBgwFoAUwD45b6V2a+CxGFcsjjEmBmt/RUswDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEAz1QJQPaPYVqbV+W/pxJm1ZXyNK5hn/pBK1JXGIPXdX4CICgalg239zxKb2Fh+H5Q38/q7ZTsNlM61ScY2k3Gdl90"...
We will look into this, Desmond. We have also contacted OneSpan to get some of their Security Keys so we can test them in-house. Hopefully, we can figure out the issue from our server logs even before their Authenticators arrive. We'll get back to you as soon as we learn something. Thanks for testing it out with our demos and FIDO Server. On 2/25/25 6:29 PM, Desmond wrote: Hi Arshad, thanks for your quick reply. Below is the link of the product I tested. It is fido2 certified. OneSpan does have a...
Is it a FIDO Alliance certified Security Key, Desmond? Can you send a link to the product on their website? I'm not sure how many models they have. When you go into Developer mode on the browser and trace Network calls, what are you seeing when you try to register a credential with the Security Key? Also, which application on our website are you testing with, and what username did you use? We can look at the logs of our FIDO server and see if we can find anything. On 2/25/25 2:21 AM, Desmond wrote:...
We are working on resolving the “android:apk-key-hash:base64” issue. Please note that it is NOT a WebAuthn Level-2 or Level-3 standard for FIDO2. It is a Google feature - there is no mention of it anywhere in https://www.w3.org/TR/webauthn-2/ or the Level-3 DRAFT: https://w3c.github.io/webauthn/. As such, it is not implemented in SKFS yet. We are looking at the possibility of implementing it for an early 2025 release - but it will help if you can ascertain that such Google proprietary capabilities...
I will let FIDO Alliance respond to questions regarding certification - ultimately, they are the authoritative source of information in that regard. WRT "Is the Server (Functional) Certification sufficient to meet all server functionalities?", the simple answer is "NO"! FIDO2 is an extraordinarily complex protocol/API. It is made much more complex than TLS ClientAuthentication (enabled by PKI) because just 2-3 trillion $ companies are driving the web standards rather than a group of objective people....
We are working on resolving the “android:apk-key-hash:base64” issue. Please note that it is NOT a WebAuthn Level-2 or Level-3 standard for FIDO2. It is a Google feature - there is no mention of it anywhere in https://www.w3.org/TR/webauthn-2/ or the Level-3 DRAFT: https://w3c.github.io/webauthn/. As such, it is not implemented in SKFS yet. We are looking at the possibility of implementing it for an early 2025 release - but it will help if you can ascertain that such Google proprietary capabilities...
Fabio, Some questions for you: 1) From your message, I am assuming you have built and are using an Android app for the registration and authentication process, rather than a desktop with a browser - is that correct? 2) If you are using an Android app, can you please provide more specifics: a) Which version of Android? b) Which API level are you targeting for the baseline? c) Which mobile device and model number are you testing with? d) Are you using the WebView component for FIDO registration and...
The issue is not in the policy, Fabio. You can use a Minimal policy for your objective. But, what you need to do is check the contents of the webservice going to SKFS before it gets there and look for the specific two components: * The origin attribute in CollectedClientData, and * The origin attribute in strongkeyMetadata and verify that they are identical before they go into SKFS. If you can capture the HTTP traffic using something like Wireshark, send us the content (after sanitizing it for sensitive...
Fabio, While that is not the right server.log file (since it does not have the content that leads to the error message you specified), we have had an internal discussion and believe we know what is causing the problem. Normally, when a browser connects to a web application and attempts to do a FIDO registration or authentication, after getting the challenge from SKFS, the browser collects some data into the CollectedClientData object and sends it into the Authenticator for a signature. One of those...
Can you please share the section of the server.log file pertaining to the preregister/register (or preauthenticate/authenticate) requests SKFS is receiving. You can find the log file as described in this section of SKFS documentation. Please note that your error message may have rotated into an older log file timestamped with the date - only the current log file is named server.log. Please locate your error message(s) in the correct log file(s) and send them. Please also note that if information...
Can you please share the section of the server.log file pertaining to the preregister/register (or preauthenticate/authenticate) requests SKFS is receiving.
I'm sorry if SACL documentation did not make it clear, Struan; we will strive to improve it so others do not have to struggle with it as you did if FIDO security policies do not need such high levels of assurance. On 10/15/24 5:38 PM, Struan Henderson wrote: Yes, thank you for clarifying. I didn't fully appreciate that. We expected to be able to enforce attestation on all Android Devices, but seeing a significant number of devices seemingly unable to provide attestation due to the issue I included...
Struan, If the device does not support AndroidKeystore attestation, the implication is that the device cannot be trusted to the extent SACL enables - the first line in the image of the message says it all. The whole point of using SACL is to leverage hardware-based protection with an attestation from the manufacturer of the device, so the business application can mitigate risks. If your business requirement is OK without any attestation for a registration, why use SACL at all? You could simply use...
Hi Struan, Need to look into this. Will need to figure out if we have those specific devices with those versions of the OS. Give us until next week please. Thanks.
Support for FIDO2 Security Keys
Depends on what kind of code Keycloak supports for the "custom authenticator". If it supports redirects, then what you've desribed should be possible. Given that SKFS always responds with messages indicating success (or failure), your demo app should be able to tell Keycloak what happened (and provide proof of that with the JWT or SAML token signed by SKFS, if necessary). However, in the long run, my recommendation is to derisk your FIDO deployment environment and consider using the built-in IDP...
This is more than likely Keycloak's policy for its own FIDO2 service implementation. Since the StrongKey FIDO Server (SKFS) requires a web-application (or an IAM system like Keycloak) to call explicit webservices on SKFS, it is highly unlikely that they have implemented something for SKFS. (There is another discussion on this topic at https://github.com/keycloak/keycloak/discussions/23101). You might want to ask the current developers from Keycloak if they know of any implementations that connect...
If you are using strongkey.com FQDNs inside your network, then make sure that all the computers that need to communicate with the hosts that have strongkey.com FQDN have the IP address as well as the FQDN defined in their etc/hosts file. If you do not have that, then they will attempt to reach the internet through DNS to talk to the real strongkey.com hosts (if the FQDN exists).
Hi, I have deployed the test application on a ubuntu which have the fqdn "fido2tutorial.strongkey.com" and i have deployed the SKFS on centos which have the fqdn "technometrics.ddns.net" adn the RPID is "strongkey.com" i am accessing the website from a different computer which is on the network and it is a windows pc. and the PEM key im using is the one that comes with the prefido test application im pasting the key.pem file below Paste your CERTIFICATE here, Ashfaqur - not your PRIVATE KEY
What is the FQDN of the Windows host? What is the value of rpid? And, can you paste your PEM-encoded certificate here? Remember that the certificate you are getting complaints about might be about your WebApp Back-End (WABE). The WebApp Front-End (WAFE) executing in the browser is communicating with the WABE, and that is where WebAuthn TLS security is being enforced. While communication between the WABE and SKFS also requires TLS, there is no WebAuthn protocol required between them - just the REST...
Hi Ashfaqur, The introduction was written from the perspective that developers will first want to quickly test SKFS using all default values, and then going back to learn more from docs.strongkey.com and customizing their installation. You should take a look at this section of the document to understand how FIDO policies are managed within SKFS: https://docs.strongkey.com/index.php/skfs-v3/skfs-administration/skfs-skfsclient-cli/admin-operations We will update our documentation to create a new Custom...
Here are answers to your questions, Ashfaqur: The FIDO/WebAuthn protocol authenticates users based on the digital signature of a private key generated for a specific relying party identifier (RPID). If the policy of the FIDO server is to require user verification (uv), then this can be satisfied using either biometric templates, PINs or Patterns (on Android) on the client side. The FIDO/WebAuthn protocol does not receive any uv detail from the client other than that it was performed on the client...
Here are answers to your questions, Ashfaqur: The FIDO/WebAuthn protocol authenticates users based on the digital signature of a private key generated for a specific relying party identifier (RPID). If the policy of the FIDO server is to require user verification (uv), then this can be satisfied using either biometric templates, PINs or Patterns (on Android) on the client side. The FIDO/WebAuthn protocol does not receive any uv detail from the client other than that it was performed on the client...
Glad to hear that. If you have any other issues, please open a new ticket/issue rather than continuing within this thread. Thanks. On 5/12/24 02:07, Ashfaqur Rahman wrote: Solved the issue, i didnt fix the correct FQDN Alternative for demo4.strongkey.com https://sourceforge.net/p/strongkeyfido/discussion/general/thread/67ae1e5e4e/?limit=25#9f20 Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/strongkeyfido/discussion/general/ https://sourceforge.net/p/strongkeyfido/discussion/general/...
You should do what the error message is suggesting: systemctl status glassfishd.service You can also go to the folder where the logfile for Payara (aka Glassfish) is available: /usr/local/strongkey/payara5/glassfish/domains/domain1/logs/server.log Post the error message here that you see in that server.log file On 5/12/24 01:55, Ashfaqur Rahman wrote: Hello i have tried installing on Centos 7 but this is showing Attachments: 2.PNG https://sourceforge.net/p/strongkeyfido/discussion/general/thread/67ae1e5e4e/91b0/attachment/2.PNG...
Rocky 9 is a better and newer operating system based on RHEL 9, Ashfaq. Definitely download and install SKFS with it. It is possible that you may have to configure the EPEL repository to be able to get the OpenLDAP packages (slapd). Search for "how to add EPEL repo to Rocky" and you will get many links telling you how to do it. Once you have EPEL, you can also install OpenLDAP and the installation will progress smoothly. On 5/12/24 00:46, Ashfaqur Rahman wrote: Im currently trying to install on centos...
The SKSO demo is working now: https://demoapps.strongkey.com/skso-citrix/ Synchronizing the Windows Login capability with a Security Key and integrating with a FIDO Server is possible. One way is to use the Security Key manufacturer's DLL (that enables local Windows Login) and wrap it with a more sophisticated capability that not only authenticates the user to Windows, but also to SSO capability that is supported by SKSO. This development can be handled either by systems integration companies - or...
Hello Ashfaq, A FIDO server only understands FIDO protocols - it does not understand anything related to operating system authentication. Windows Login is usually accomplished with the manufacturer of the Security Key providing a "middleware" component (usually some DLL) that is then integrated with your AD environment. This is an independent authentication, completely separate from FIDO authentication for web/mobile applications. Some Security Key manufacturers can, technically, integrate a FIDO...
Hi Hansaebyeol, If I understand your write-up and picture correctly, you are essentially setting up helloworld.com as a relay service for users to use a single mobile (authenticator) app to authenticate to multiple companies. Each company's keys are stored in a unique domain with its own policy, while your mobile app figures out which RP the user is trying to connect to, and directs them to the appropriate RP site/service where they are authenticated. This implies that you are generating unique key-pairs/credentials...
See answers below, Hansaebyeol. Arshad On 4/12/23 6:28 PM, Hansaebyeol Kang wrote: @arshadnoor https://sourceforge.net/u/arshadnoor/ @push2085 https://sourceforge.net/u/push2085/ First of all, thank you for your quick response. Before I ask you a question, I think I asked the question in the other direction. I modified the diagram described earlier. Before I explain what I'm trying to do, I use 1 and 7 of DID 1-8 when it was first installed. This is fine, but if you want o keep this orderly, you...
See answers below, Hansaebyeol. Arshad On 4/12/23 6:28 PM, Hansaebyeol Kang wrote: @arshadnoor https://sourceforge.net/u/arshadnoor/ @push2085 https://sourceforge.net/u/push2085/ First of all, thank you for your quick response. Before I ask you a question, I think I asked the question in the other direction. I modified the diagram described earlier. Before I explain what I'm trying to do, I use 1 and 7 of DID 1-8 when it was first installed. This is fine, but if you want o keep this orderly, you...
Hi Hansaebyeol, Pushkar will be responding to you in some detail, but I just wanted to clarify one item. If you installed SKFS with all default values, it automatically creates 8 domains and assigns each one a unique policy (To see what those policies are like, take a look at our demo on https://demo.strongkey.com/fidopolicy). But, you do NOT have to create 8 domains each time you add a new service - you only need a new domain for each unique RPID. You can either reuse the existing domains - #2 through...
Yes, this is possible. It is accomplished using additional "cryptographic domains" (aka FIDO domains). When you install SKFS, it automatically installs one "FIDO domain" and enables the use of a single RPID. However, to support additional RPIDs, you need to create additional "FIDO domains". Once created, you can assign a unique RPID to that domain. However, the web application making webservice requests to the SKFS must know the unique domain ID (DID) and call the web service by specifying the appropriate...
Hi Tomas, Good to communicate with you again on the forum; it has been a long time. :-) I got past the problem I was having. For some reason, within the configuration I described, the EAR was not getting deployed to Wildfly even though ejbca.ear was in Wildfly'sdeployment folder. However, upon restarting Wildfly, EJBCA did get deployed and was available. Right now, I'm wrestling with the fact that the SOAP webservice client I'm testing, continues to return a Connection Refused response for even the...
Hello, In trying to install the current release of EJBCA CE (7.9.0.2) with its underlying components: Rocky Linux (64-bit) 8.6 OpenJDK 11.0.16 (64-bit) MariaDB 10.8.3 (64-bit) MariaDB Connector 2.7.4 Wildfly 24.0.1-Final Apache Ant 1.10.12 I've run into problems in the deployear step as compilation of some Java code within EJBCA throws up errors. Suspecting issues with the latest release of Ant, I downgraded to 1.8.2 - it fails again in a different place in the build process because ejbca.ear does...
FIDO protocols are designed to only work with web-origins for which they are configured. So, if a Magento instance is running at www.example.com, then the FIDO server serving that instance will only allow keys to be registered and used for example.com. However, if there is a site that uses 3 Magento instances - example.com, happyday.com and greatwidgets.com - wishes to use a single FIDO server, then the app.json file must include all three origins when using that FIDO server. You are not sending...
Hi Jerin, The problem is that you're running the FIDO server with the default appid, which is pointing to "https://demo.strongauth.com:8181/app.json". This will only work if the Magento instance was running on strongauth.com. In order to make this work with your Magento instance - which is probably running on a different URL origin, you have to modify the app.json file of your FIDO server configuration to your DNS top-level-domain + 1 (TLD+1) value, restart the FIDO server and then attempt to register...
Initial import
Add initial directories
Hi Shailesh, Unfortunately, we have stopped maintaining StrongKey. This was primarily...
Enable FIDO U2F strong-authentication on SF
Home
Announcing the 2.0 release of the StrongKey CryptoEngine (SKCE), a Java program that...
Announcing the 2.0 release of the StrongKey CryptoEngine (SKCE), a Java program that...
Hi Ken, I'm afraid we're not supporting the original StrongKey anymore (lots of reasons,...
FIDO-enable a JEE7-JSF application
Home
Home
Initial commit