Skip to main content

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-25) Deploy JAAS Artifacts in Application

  • From: "arjan tijms (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-25) Deploy JAAS Artifacts in Application
  • Date: Thu, 23 May 2013 22:18:59 +0000 (UTC)
  • Auto-submitted: auto-generated


    [ 
https://java.net/jira/browse/JAVAEE_SPEC-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=364516#action_364516
 ] 

arjan tijms commented on JAVAEE_SPEC-25:
----------------------------------------

{quote}
I think in the bare minimum we need to have something as simple as this:

{code}
@SecurityProvider
public class MySecurityProvider {

@Inject UserService userService;

@OnAuthentication
// The parameters could suit the credentials mechanism being used.
public Principal getPrincipal(String username, String password) { // 
Construct the principal using the user service. }

@OnAuthorization
public String[] getRoles (Principal principal) { // Construct an array of 
roles using the principal and user service. }
{code}
{quote}

I fully agree with this, even so much that I earlier proposed a largely 
identical thing in JAVAEE_SPEC-9 ;)

{code}
@AppLoginModule
public class MyAuthenticator implements PasswordLoginModule {

    private User user;

    @Inject
    private UserService userService;

    public void authenticate(String name, String password) {    }

    public String getUserName() {  }

    public List<String> getApplicationRoles() {  }
}
{code}

{quote}I know this is easier said than done.{quote}

Implementing this appeared to be _more or less_ doable using a JASPIC SAM 
that delegates to a CDI bean. I prototyped this in the OmniSecurity project, 
e.g. with [this 
SAM|http://code.google.com/p/omnisecurity/source/browse/src/org/omnifaces/security/jaspic/OmniServerAuthModule.java].
 The emphasis is on more or less, since JASPIC doesn't natively support CDI. 
If it did, such a simplified login module would really not be that difficult.

Of course the point is that such an {{@SecurityProvider}}/{{@AppLoginModule}} 
should become a standard part of Java EE.

{quote}Maybe the right approach is that this is a much simpler approach 
geared towards developers whereas JAAS, JASPIC, etc are geared towards 
vendors where a more complex programming model is useful.{quote}

That's an interesting discussion. I personally think JASPIC doesn't equate a 
complex programming model at all. It's understandable that one might think it 
is complex after reading through the JASPIC spec, which is written in a 
rather formal writing style. However, when actually trying some code 
examples, it becomes clear that there's not _that_ much to it.

The main concept is basically a single method called {{validateRequest}} that 
functions pretty much like the {{doFilter}} method in a Servlet Filter, from 
there you pass a username and optionally one or more roles into a callback 
handler. E.g.

{code}
public AuthStatus validateRequest(MessageInfo messageInfo, Subject 
clientSubject, Subject serviceSubject) throws AuthException {

    CallerPrincipalCallback callerPrincipalCallback = new 
CallerPrincipalCallback(clientSubject, "test");
    GroupPrincipalCallback groupPrincipalCallback = new 
GroupPrincipalCallback(clientSubject, new String[] { "architect" });

    handler.handle(new Callback[] { callerPrincipalCallback, 
groupPrincipalCallback });
}
{code}

If anything, I think the perceived complexity comes from JASPIC simply being 
rather low-level and still at Java 1.4. It's a bit like GenericServlet vs 
HttpServlet. It's not that the Servlet model is complex, but GenericServlet 
is well, very generic. If you'd only had that you would need to do a lot of 
casting and create a lot of boilerplate code. A rather simple base class 
specific for Servlet Profile SAMs would go a long way (I proposed this in 
JASPIC_SPEC-17).

I created an example of a SAM based on such base class here: 
[TwoFactorServerAuthModule|https://github.com/arjantijms/two-factor-sam/blob/master/src/main/java/net/eisele/glassfish/twofactorsam/TwoFactorServerAuthModule.java].

With just a tiny bit of helper code, registering a username and roles with 
the container from within a SAM then looks like this, which IMHO is much 
easier to use:

{code}
httpMsgContext.registerWithContainer(
    authenticator.getUsername(), 
    authenticator.getRoles()
);
{code}

{quote}As an aside, Scott Ferguson (Resin Chief Architect) was resistant to 
JASPIC since he belived there is not likely to be a large number of security 
vendors that would be that interested in plugging into application servers 
and JAAS itself would only be used by developers that need very customized 
security.{quote}

Well, for the projects I'm involved with we're using JASPIC auth modules for 
anything from a form based login module that integrates better with JSF than 
the build-in Servlet version, to auth modules for logging in with Facebook, 
Twitter, LinkedIn and such.

I don't think any of those use cases would really qualify as being very 
customized security. If it weren't for JASPIC, we most likely would have been 
required to completely ignore Java EE security and implement the security 
requirements using e.g. Filters and interceptors and such.

I do think there's a lot to be improved in JASPIC (and even more for Java EE 
security in general). But specifically for JASPIC I think that's for a large 
part just modernizing it, just like was recently done for JMS 1.1. 

Another issue of concern is the documentation of JASPIC. The spec document 
isn't very suited for most application programmers to learn how to use it, 
but other than the spec there's not much out there. Even Oracle's own Java EE 
tutorial doesn't explain JASPIC. Because of that many people simply don't 
know about JASPIC and how it can be used.





> Deploy JAAS Artifacts in Application
> ------------------------------------
>
>                 Key: JAVAEE_SPEC-25
>                 URL: https://java.net/jira/browse/JAVAEE_SPEC-25
>             Project: javaee-spec
>          Issue Type: New Feature
>            Reporter: reza_rahman
>            Assignee: ldemichiel
>
> Currently there is no portable way of deploying JAAS artifacts including 
> custom login modules with the application. This is a potential usability 
> issue, especially in cloud environments.
> It may be very helpful to have portable annotations or XML for this, just 
> like we now have for data sources and JMS resources. As part of this 
> effort, it would also be great if the programming model around JAAS login 
> modules could also be modernized using annotations.
> Do let me know if anything needs to be explained further - I am happy to 
> help.
> Please note that these are purely my personal views and certainly not of 
> Oracle's as a company.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[javaee-spec issues] [JIRA] Created: (JAVAEE_SPEC-25) Deploy JAAS Artifacts in Application

reza_rahman (JIRA) 05/13/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-25) Deploy JAAS Artifacts in Application

arjan tijms (JIRA) 05/21/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-25) Deploy JAAS Artifacts in Application

reza_rahman (JIRA) 05/23/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-25) Deploy JAAS Artifacts in Application

arjan tijms (JIRA) 05/23/2013
 
 
Close
loading
Please Confirm
Close