Hi,
On Thu, Apr 16, 2015 at 2:01 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> If it demonstrates how aspects of JSR 375 can work, would it make sense to
> merge your collaborative effort into either the "proposal" or "examples"
> repo, too?
>
> It's a little easier to track changes and ideas in just those 2 or 3
> repositories than 5 or more others.
Indeed. This application from Adam however is an actually working full
application, which I think warrants having an extra repo. 2 years ago
I created something like this too, which demonstrates a very early
version of what the PR I send to Adam contains:
https://github.com/javaeekickoff/java-ee-kickoff-app
Keeping track of the repositories is indeed a challenge. I have the
OmniSecurity repo as well where the experiments originate from.
Anyway, the PR demoes:
* Authentication
- Authentication mechanism - based on JASPIC
- Communication between authentication mechanism and identity store
- CDI bean manager lookup
- Identity store - CDI bean with credential specific interface
I'll take a look soon where this can best be put in the JSR 375 repo.
Kind regards,
Arjan
>
> Cheers,
>
> Werner
>
>
> On Thu, Apr 16, 2015 at 12:10 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>> Hi,
>>
>> On Thu, Apr 16, 2015 at 10:23 AM, Adam Bien <abien_at_adam-bien.com> wrote:
>> > Hi Arjan,
>> >
>> > thanks! It works.
>> >
>> > All tests are green:
>> > https://github.com/AdamBien/secspike/blob/master/todo-st/src/test/java/org/specspike/todo/reminders/boundary/ToDosResourceIT.java
>>
>> Great!
>>
>> What you think about the look of the code?
>>
>> The idea would be that the app developer can freely mix between
>> HttpServerAuthModule and IdentityStore, and that both can be either
>> installed at the server or be provided by the application and that for
>> both a couple of default implementations are provided by the spec.
>>
>> Not shown yet in this prototype, but HttpServerAuthModule should
>> probably be a CDI bean as well.
>>
>> The challenge of this EG is now to standardize this (or something like
>> it, of course), and make sure it works on every server ;)
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> >
>> > cheers,
>> >
>> > adam
>> >> On 15.04.2015, at 16:43, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Wed, Apr 15, 2015 at 9:31 AM, Adam Bien <abien_at_adam-bien.com> wrote:
>> >>> My goal is to keep the authorization / authentication part as
>> >>> convenient, elegant and usable as only possible,
>> >>>
>> >>> Should we start with user name / password login implementation and
>> >>> in-memory IdentityStore? We could copy this app for each scenario and reuse
>> >>> the already existing sec examples.
>> >>
>> >> I quickly added security to this in a fork and did a PR ;)
>> >>
>> >> It's by default configured for a BASIC authentication mechanism with a
>> >> username/password identity store. Optionally it can be switched to the
>> >> header based authentication mechanism which uses a token identity
>> >> store.
>> >>
>> >> The BASIC *authentication mechanism* is implemented via the following
>> >> JASPIC auth module:
>> >>
>> >> public class BasicAuthModule extends HttpServerAuthModule {
>> >>
>> >> @Override
>> >> public AuthStatus validateHttpRequest(HttpServletRequest request,
>> >> HttpServletResponse response, HttpMsgContext httpMsgContext) throws
>> >> AuthException {
>> >>
>> >> String[] credentials = getCredentials(request);
>> >> if (!isEmpty(credentials)) {
>> >>
>> >> UsernamePasswordIdentityStore identityStore =
>> >> getReferenceOrNull(UsernamePasswordIdentityStore.class);
>> >> if (identityStore != null) {
>> >> if (identityStore.authenticate(credentials[0],
>> >> credentials[1])) {
>> >> return
>> >> httpMsgContext.notifyContainerAboutLogin(identityStore.getUserName(),
>> >> identityStore.getApplicationRoles());
>> >> }
>> >> }
>> >> }
>> >>
>> >> if (httpMsgContext.isProtected()) {
>> >> response.setHeader("WWW-Authenticate", "Basic realm=\"test
>> >> realm:\"");
>> >> return httpMsgContext.responseUnAuthorized();
>> >> }
>> >>
>> >> return httpMsgContext.doNothing();
>> >> }
>> >>
>> >> private String[] getCredentials(HttpServletRequest request) {
>> >>
>> >> String authorizationHeader = request.getHeader("Authorization");
>> >> if (!isEmpty(authorizationHeader) &&
>> >> authorizationHeader.startsWith("Basic ") ) {
>> >> return new
>> >> String(parseBase64Binary(authorizationHeader.substring(6))).split(":");
>> >> }
>> >>
>> >> return null;
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >> The username/password *identity store* is implemented via the
>> >> following CDI bean:
>> >>
>> >> @RequestScoped
>> >> public class TestUsernamePasswordIdentityStore implements
>> >> UsernamePasswordIdentityStore {
>> >>
>> >> private static final long serialVersionUID = 1L;
>> >>
>> >> @Override
>> >> public boolean authenticate(String username, String password) {
>> >> return true;
>> >> }
>> >>
>> >> @Override
>> >> public String getUserName() {
>> >> return "testuser";
>> >> }
>> >>
>> >> @Override
>> >> public List<String> getApplicationRoles() {
>> >> return asList("USER");
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >>> Should we use GF 4.X as reference server?
>> >>
>> >> I tested the above on GlassFish 4.1 (requesting
>> >> http://localhost:8080/todo/resources/todos) and it works without
>> >> needing any additional config.
>> >>
>> >> Do note that for deploying on a stock GlassFish 4.1 a
>> >> glassfish-web.xml had to be added. This is *really* unfortunate. For
>> >> usability the mandatory presence of either this file or setting
>> >> default group to principal mapping (see
>> >> https://blogs.oracle.com/bobby/entry/simplified_security_role_mapping)
>> >> just has to go.
>> >>
>> >> For JBoss (EAP/WildFly) such mapping file is not needed, but there a
>> >> (dummy) security domain has to be added, which is again a *really*
>> >> unfortunate thing and a big impediment for usability. Unrelated to
>> >> security, I got a "Could not find MessageBodyWriter for response
>> >> object of type: java.util.ArrayList of media type:
>> >> application/octet-stream" when I requested the above mentioned URL on
>> >> JBoss WildFly 8.2.
>> >>
>> >> On WebLogic this unfortunately doesn't work at all, since there CDI is
>> >> initialized too late and thus not available to the auth mechanism.
>> >>
>> >> So there are still a few small (but very important!) hurdles to
>> >> address to make this really user friendly and portable on all servers,
>> >> but I think this is a nice start ;)
>> >>
>> >> Kind regards,
>> >> Arjan
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>> cheers,
>> >>>
>> >>> adam
>> >>>
>> >>> I broke my underarm, so my coding speed suffers a bit, but next week
>> >>> should be back to normal.
>> >
>
>