I'm using XAdES to validate message which are using xades-t.
But some counrties in europe do not rely on the certificate chain to a valid root CA.
How would I go about in implementing a different way of validating certificates in xades4j?
Any suggestions are greatly appreciated.
kind regards
When you create a XadesVerificationProfile you must supply a CertificateValidationProvider. The library includes an implementation based on Java's PKIX classes, but you can implement another provider with custom validation login and supply it to the XadesVerificationProfile constructor.
Related
On a project we spent considerable effort to work around basic authentication (because webdriver tests were depending on it, and webdriver has no api for basic authentication), and I remember basic authentication in the URL clearly not working. I.e. could not load http://username:password#url
Just google "basic authentication in url" and you will find tons of people complaining: https://medium.com/#lmakarov/say-goodbye-to-urls-with-embedded-credentials-b051f6c7b6a3
https://www.ietf.org/rfc/rfc3986.txt
Use of the format "user:password" in the userinfo field is deprecated.
Now today I told this quagmire to a friend and he said they are using http://username:password#url style basic authentication in webdriver tests without any problem.
I went in my current Chrome v71 to a demo page and to my surprise I found it indeed very well working: https://guest:guest#jigsaw.w3.org/HTTP/Basic/
How is this possible?? Are we living in parallel dimensions at the same time? Which one is true: is basic authentication using credentials in the URL supported or deprecated? (Or was this maybe added back to Chrome due to complaints of which I can't find any reference?)
Essentially, deprecated does not mean unsupported.
Which one is true: is basic authentication using credentials in the URL supported or deprecated?
The answer is yes, both are true. It is deprecated, but for the most part (anecdotally) still supported.
From the medium article:
While you would not usually have those hardcoded in a page, when you open a URL likehttps://user:pass#host and that page makes subsequent requests to resources linked via relative paths, that’s when those resources will also get the user:pass# part applied to them and banned by Chrome right there.
This means urls like <img src=./images/foo.png> but not urls like <a href=/foobar>zz</a>.
The rfc spec states:
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible. Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).
So the use of user:pass#url is discouraged and backed up by specific recommendations and reasons for disabling the use. It also states that apps may opt to reject the userinfo field, but it does not say that apps must reject this.
I'm using the aws-sdk gem and I don't understand the difference between a Client and a Resource. This blog post isn't super helpful:
Each service module has a Client class that provides a 1-to-1 mapping
of the service API. Each service module now also has a Resource class
that provides an object-oriented interface to work with.
link
The documentation on the two classes isn't much help either:
http://docs.aws.amazon.com/sdkforruby/api/Aws/S3/Client.html
http://docs.aws.amazon.com/sdkforruby/api/Aws/S3/Resource.html
So what am I not understanding?
I was looking for this and found :
https://aws.amazon.com/blogs/aws/java-sdk-resource-apis-preview/
"Instead of exposing all of the methods of the service as part of a single class, the resource-style API includes multiple classes, each of which represents a particular type of resource for the service.... Code written to the new (resource-style) API will generally be shorter, cleaner, and easier to comprehend"
I'm attempting to query an REST service with fairly limited idea of how to approach it.
I'm using Delphi XE6 (upd 1)
The company providing the API have said that: "The API is implemented as JSON via SSL"
and they go on to say that:
Access to any API endpoint requires authentication via signed requests, created with publicand secret API
keys
I have the keys defined above.
The signature is an HMACSHA256 hash of a string containing the request contenttype, host,
URL, date timestamp (matching the request Date header) and request content (eg POST
parameters) separated by a single newline, and passed with the public key in a custom header
XAPIAuthorization along with the public key, in the format PUBLICKEY:SIGNATURE
I understand each request needs to be signed.
How do I sign an http request with Delphi XE6?
The confusion for me at the moment is it seems Delphi has a number of built-in components have accessing RSET servers and parsing the JSON returned. I can't see any obvious way of signing requests using these components.
Specifically is there any help from the built-in Rest components or do I have to provide my own solution?
I have a working project that uses the FOSUserBundle to handle all things user related, including logging into the system. Now, I'm building an API, and would like users to be able to log into the system by sending their credentials via JSON over HTTPS. I'd also like to be able to use the _remember_me cookie.
So, I need to be able to send either those JSON-decoded credentials or the _remember_me cookie to the FOSUserBundle login mechanism, but I'm not quite sure how to do it. Any suggestions or nudges in the right direction would be greatly appreciated.
You need to create a custom authentication provider and a security factory. This is quite an advanced task, but there's a tutorial here that can help you. http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html
When you create your factory class (implementing the SecurityFactoryInterface) make sure you assign getPosition() to http. The several authentication factories will be called in a strict order depending on their position, so bear in mind that the remember_me position - that takes care of the remember me functionality (provided it is enabled in your security.yml file) - will kick in earlier than the http authentication you are about to implement.
Besides the tutorial above, you can take a look at and study the following built-in authentication factory that can provide useful information:vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Security/Factory/HttpDigestFactory.php
I am trying to build my application's admin UI using sling's userManager REST interface, but I would like to customize the json rendering. For example, I would like the response of "Get group" to include the members only if the requestor is a member.
I started by adding libs/sling/group/json.esp but I don't understand how I can get hold of the default response and customize it. Even if I had to query and form the json from scratch, where can I find information about APIs available to get this data from JCR/Sling?
I found that I could use ResourceTraversor to dump the resource object in json form but using new Packages.org.apache.sling.servlets.get.impl.helpers.ResourceTraversor(-1, 10000, resource, true) in the esp throws up an error
There are a few things to note here.
First, you should avoid putting your code under the libs directory. Your app code should live under the apps directory. When attempting to resolve a servlet for a URI, Sling will check apps before it checks libs so if you need to completely override functionality delivered with Sling, you would place your code in apps.
Second, what is (probably, depending on how you have things setup) happening when you request http://localhost:8080/system/userManager/group/administrators.tidy.1.json is the request is being handled by Sling's default GET servlet, because it finds no other script or servlet which is applicable. For research purposes it might be worth looking at the code for the default get servlet, org.apache.sling.servlets.get.impl.DefaultGetServlet, to see what it's using to render JSON. If you need to handle the rendering of a user group in a manner different than what the default GET servlet is doing, then you would need to create a servlet which is listening for requests for resources of type sling/group. It would probably be ideal to create a servlet for this purpose and register it with OSGI. http://sling.apache.org/site/servlets.html provides the various properties you would need to set to ensure the servlet resolver finds your servlet. Your servlet then would handle the request and as such would have direct and easy access to the requested resource.
Third, the particular need you specified is that you do not want the group members to render unless the requesting user is a member of the group requested. This is more of an access control issue than a rendering issue. Sling and Jackrabbit, out of the box, make as few assumptions as possible concerning how you might want your application to be setup. That being the case, you need to establish the access controls that are applicable for your particular use case. The wiki post on Access Control in the Jackrabbit wiki ( http://wiki.apache.org/jackrabbit/AccessControl ) goes into this to an extent.
Using directions from Paul Michelotti's answer, I researched further and found a suitable solution to my problem.
Sling accepts request filters (javax.servlet.Filter) through SCR annotations like the one below
#SlingFilter(scope = SlingFilterScope.REQUEST, order = Integer.MIN_VALUE)
Every request is passed down to the filter before it is processed by the servlet. Using the resourceType, I was able to distinguish requests to group.1.json and group/mygroup.1.json. Since the filter also has access to the current user, I was able to decide to deny the request if it did not abide by my security model and return a 404 status code.
Please refer to this page for details on filters. You can also check out the sample project urlfilter for directions on usage.