Hi.
I am one of the folks currently working on the JASPIC TCK.
I just started following some of this thread and was hoping I might be
able to add a little to it.
Please see my comments below.
On 11/3/14, 6:20 PM, arjan tijms wrote:
> Hi,
>
> On Mon, Nov 3, 2014 at 8:44 PM, Edward Burns<edward.burns_at_oracle.com> wrote:
>>>>>>> On Sat, 01 Nov 2014 10:14:10 +0000, Mark Thomas<markt_at_apache.org> said:
>> Ok, these are actionable responses. Arjan, can you please get back to
>> the list with a feel for if it's possible to do as you said with the
>> Geronimo JASPIC impl?
> Yes, I took a look at it a while back and will do some more studies soon.
>
> At any length, JASPIC does not have a major amount of functionality to
> implement (like e.g. JSF). Slight simplified it consists of:
>
> 1. The Servlet container calling the user provided auth module at the
> right times
> 2. Implementing a small amount of "API classes with code" (mostly
> AuthConfigFactory)
>
> and actually optional, but most users would expect this:
>
> 3. Some way to register the auth module at the container level (as
> opposed to registering from within the application archive)
>
> If I'm not mistaken the bulk in actual implementation code is
> typically in item 3, which is usually some way to parse an XML file
> and extract some details like the auth module class and whether it's
> required etc. I'm not 100% sure how the TCK approaches this, but since
> item 3. is fully container specific I guess that the most minimal
> implementation could possibly even leave that out.
The (JASPIC) TCK specifies it's own AuthConfigFactory. When the
appserver starts, our AuthConfigFactory is loaded. It then reads an XML
file and uses the info from that xml file to register our auth config
providers. The server auth modules (SAMs) are not loaded from XML files
but instead are loaded directly when our tcks providers get loaded. So
we load ACP's from an xml file but not SAMs.
The largest focus of the JASPIC TCK was to test the runtimes ability to
interact with AuthConfigFactorys and AuthConfigProviders's as well as
some of the interactions with auth context and auth configs. We chose
not to do much with the SAMs instead focusing on the other components
because we didn't see many ways to validate the testable assertions in
each vendors SAM. If folks believe the TCK is missing any coverage or
there are areas you are unsure of, please pass the info along.
Arjan, I know you and Ron Monzillo had some discussions on possible
tests to add to the JASPIC TCK. We did add a couple new JASPIC tests
based on your input. They will not be available until Java EE 8 but
they were added. We are not opposed to adding new tests, as a matter of
fact, if folks have suggestions for generic compatibility tests they
would like to see added, please do feel free to give us feedback on
those potential new tests. We can't guarantee new tests will always
make it into the TCK but we do give them serious consideration.
Again, if folks are interested in having more tests added to the TCK,
please supply us with spec reference being tested, and the test
specifics you are interested in.
thanks,
paul