I have been learning about PKCS#11 and now I want to create some applications using it in C. Now I have the following question,
1) I think the shared library for a token comes with vendor of the token, Am I right?
2) Which open source library for PKCS#11 (in C) I can use if I have a token and not the its shared library?
1) I think the shared library for a token comes with vendor of the token, Am I right?
Yes in most cases it does.
2) Which open source library for PKCS#11 (in C) I can use if I have a token and not the its shared library?
OpenSC project ships PKCS#11 library which supports several cards and tokens.
Related
We are in the process of designing a front-end application with Angular which will call a jBASE server through RESTful APIs. APIs are created from jBASE component called jAgent.
Does jAgent support creating and verifying JWTs?
If not, what is the best way to handle authentication/authorization for the Angular application?
If we need to use JWTs, do we have to use a authentication middleware application (.NET Core or node.js) for that?
Great question! At the moment there is no handler within jAgent and our recommendation is to implement this, and advanced web server/API gateway technology by way of other applications like HAproxy or Kong.
An expansion of jAgent functionality to include things like this is something we're still considering but keep in mind, the power of jBASE lies in its native interactions with the host OS. Since there is no virtual OS layer it can be easier to plug and play off the shelf things to fill in for additional functionality, which gives you the flexibility to bring your own tooling.
In summary:
Not at the moment
Using an off the shelf package to act as your API gateway
Subject to the package you choose
That relegates jAgent to management of the API layer as it exists on the PICK/jBASE side while the off the shelf package manages your API security layer.
One other note for you--I noticed that you included a link to the old jBASE docs hosted on HelpJuice. It's worth mentioning that we've migrated those docs to docs.zumasys.com. You'll find the docs there to be more up to date, and also completely open sourced--part of the migration included their move to a GitHub repo, where we're happy to take community contributions.
For reference, the article you mentioned is available at https://docs.zumasys.com/jbase/connectivity/jagent/introduction-to-jagent-rest-services/.
Update:
One of our engineers has a program that will use openssl to generate the tokens for you, which you can find at https://github.com/patrickp/wjwt.
You will need openssl installed on the machine and in the path.
The WJWT.TEST program shows the usage. The important piece is the SECRET.KEY which is your internal KEY you use to sign the payloads.
When a user first authenticates you create the token with SIGN. Claims are any items/fields you wish to save/store. Do NOT put sensitive data in here as it is viewable by anybody. The concept is we sign this with our key, give it back to the client. On future calls the client sends the token and we pull it and call the VERIFY function which basically re-signs the payload and validates the signatures match. This validates the payload was not manipulated.
Activities such as expiration you would build into your code.
Long term we plan to take this library and refactor the code into our MVDB Toolkit library with more functionality. That library is something we provide to jBASE customers at no additional charge.
I'd like to use the AWS C++ SDK in a C library. However, the library build only supports C++.
Does anyone know if there's a C wrapper for the SDK ? There are far too many methods to easily change the code.
Or should I just call the mangled methods (not portable) ?
You can write a wrapping C++ code, which wraps the library, and export the main methods in 'C' mangling. using 'extern "C"' at the functions decelerations.
I've writtend such a wrapper for having s3 client, having methods to create/destroy s3 client/transfer client, and upload/download a file (code is company proprietary so I can't share it).
I think this is better than implementing the http api using curl, as writing your own client is complex, and you may want other features (and bug fixes) which you get out of the box if you use the sdk (such as using kms,recovery handling etc.)
I am trying to replace HSM(s) with my software-only application and integrate with PKCS11. The problem I have with that is all of PKCS api functions deal with slots and tokens which are not a part of my software application. Are there examples out there that I can look up to see how a software application can be used to imitate an HSM and integrate with PKCS ?
When you are dealing with HSM's you have to deal with slots and tokens. You have to modify your software slightly to accommodate this.
There are 2 ways you can use the PKCS#11, PKCS#11 Wrapper or PKCS#11 Provider. The Wrapper is the api that calls the native functions of the HSM library (.dll or .so) directly. The Provider uses the Wrapper under the hood, but gives you the convenience of using it with Java KeyStore api.
Considering your case, the Wrapper might not be fit for you, because it involves writing new classes to integrate with the HSM. You could use the provider.
Java has very good documentation of the PKCS11 Provider here. There is also a very good third-party library called IAIK, here is their provider documentation. Even though you use the Provider in your software application, trivial code changes are inevitable.
Where ever you have used the KeyStore api, you may have to make changes there. And initially, when your software loads, you have to load a configuration file for the PKCS11 provider that tells which slot number and the token to connect to.
IAIK has very good examples too, and their provider library is only free for development purposes.
SAML 2.0?
OpenId?
OAuth 2.0?
CAS?
And others?
I know they all can do SSO, but I want to find out what are all standard protocol nowadays we used for SSO that covers 80% of market?
Anyone knows how do I find the result?
There is no standard protocol because it depends on the use case e.g.
Microsoft Enterprise uses WS-Fed.
Java Enterprise uses SAML-P.
Native (mobile) uses OAuth2 for consent. If you want authentication on top of this, add OpenID Connect.
And it also depends on the STS - not every STS supports all the above.
I have some problems with creating static libraries.
Let say I have the static library A which I created and I included that to static library B with the relevant header files. I need to create a static library C which will be my final library and it it should include static library B which implicitly include the static library A. So I need to hide both implementation details of library A and B in the library C but it should not visible to the end user. Only an interface will be provided.
1) So let say my static library A uses some dependencies which are some libraries in the SDK. So do I need to import in my final project although I included the library C?
At the moment I am having some build issues when I tried above.
2) Can we bundle 3rd party static libraries inside our static libraries and distribute only our library?
3) Let say we are downloading some 3rd party code. Using that we are creating static libraries. Can we distribute a static library using 3rd party code. If so do we need to expose the code?
4) How does the static library acceptance in App store. Is it like the normal process? (I mean projects bundles with static libraries)
Thank you,
Regards,
Dilshan
Wow. Four questions. If only I could get 4x the rep. :)
Yes, you need to include the frameworks in the App's project. Linking a framework in a static library only creates references to symbols that don't exist. These need to be resolved during app link by linking in the frameworks to the final app.
I take it you're thinking about selling an SDK of static lib files and header files. Yes, it is technically possible to link it all into one giant library (see ar(5) for details) and ship the library and select header files, but see answer #3.
Depends on the license for the third-party library. Consult legal counsel if you have questions.
Most apps have a static library linked in to the app. For example, the vast majority of free apps include AdMob or similar advertising packages, which are distributed as a static library. A static library doesn't, per se, violate any Apple submission policy, but the library can violate a policy, such as including undocumented APIs. If the static library violates a submission policy, an app that uses it will be rejected, even if the app doesn't use that feature.
Incidentally, you can't completely "hide" the interfaces of library A and B (from your example.) If you could, Apple would and it would not be possible to use undocumented APIs. All you can really do is leave them out of the headers and documentation.