Arkin,
Please explain why you feel that JAAS docs are not accurate in regards to
access control or
not what you would expect.
When we originally designed JAAS we had a Role class and took it out due it
being under
specified. Would be interested in any thoughts here that anyone may have.
Do you care about the underlying OS thread identity, that is when I do a
Subject.doas()
the OS thread identity is not changed ?
I believe that container vendors will exploit JAAS as a programming model
but may
not consumer of JAAS.
Thanks,
Anthony Nadalin
_______________________________
mailto:[EMAIL PROTECTED]
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
Sent by: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Integrating J2EE and JAAS
I'm doing JAAS for EJB/Servlet right now, and the JAAS access control
does play nicely, though not what you expect from the JAAS docs.
You can get the Subject from the current thread of execution, and from
the Subject obtain a Principal and a RoleCredential which the EJB server
then exposes to the application and uses to enforce role-based security.
The remaining capabilities of JAAS are made available to the resource
managers (JDBC, LDAP, ERP, etc) used by the application.
arkin
(PS: details are a bit sketchy on that, but JSR-58 has been set up to
address these issues and detail EJB + JAAS for J2EE 1.3)
Anthony Nadalin wrote:
>
> Oh, please discuss !
>
> >2)-->authorization: checking whether a user is allowed to access some
> >resources. This is definitively not needed by the EJBServer, because the
> >EJB and the JAAS access controll logic are uncorrelated (I'm ready to
> >discuss that in detail).
>
> Thanks,
> Anthony Nadalin
> _______________________________
>
> mailto:[EMAIL PROTECTED]
>
> Please respond to A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
> Sent by: A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Integrating J2EE and JAAS
>
> About integrating JAAS into EJB (J2EE),
>
> What do JAAS deals with and where is it needed:
>
> 1)-->authentication could be needed for tow purposes:
> 1a) -->For getting security attributes of a user, that sits on a
> machine in the intranet environment or in a managed extranet environment
> (verry nice). J2EE solve this problem with the concept of application
> components, that run in some kind of application containers provided by
> the J2EE provider. JAAS provides clients with a nice way for
> communicating user sec. attr. to their containers, and it is the corner
> where we will need JAAS anyway.
> 1b)-->For solving the following form-based authentication
> problem outlined by Laird:
> <hint>
> when using form-based authentication, you need some way for transmitting
> the security attributes you got from the client to the web server
> environment, so it can be asociated with the communication subsystem.
> </hint>
> <solution>
> The JAAS's LogingContext.loging() method could be used to perform this
> task.
> </solution>
> 1c)-->But JAAS couldn't be used for getting security
> attributes of a user that sits on a browser somewehre in the internet.
> For this, we need some kind of HTTP authentication (basic, form, ssl).
>
> 2)-->authorization: checking whether a user is allowed to access some
> resources. This is definitively not needed by the EJBServer, because the
> EJB and the JAAS access controll logic are uncorrelated (I'm ready to
> discuss that in detail).
>
> 3)--> JAAS doesn't deals with context propagation, so transmitting
> security attributes from ejb clients (stand alone, servlets) to ejb
> server couldn't be handled by JAAS.
>
> In summary, let's say JAAS can be used for authentication when
> implemeting J2EE Java-Clients.
>
> So if you see any other integration point between EJB(J2EE) and JAAS, or
> someting wrong in that countered above, let me know your opinion.
>
> Thanks.
> --
> Francis Pouatcha
>
> MATHEMA Software GmbH
> http://www.mathema.de
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
