> My question is: what can I do to propagate what I have in the web tier
> (principals? security context? subject?) to the remote service, so that
> @RolesAllowed({myrole1}) actually checks against the attributes of
> the AttributePrincipal of the web app calling?Apache Shiro purports to solves this problem. http://shiro.apache.org/ Bill On Wed, Jul 25, 2012 at 5:52 AM, Maciek <[email protected]> wrote: > Hi everyone, > > I have a set of web applications that have been casified using the > "official" Java web filters: > > 1. org.jasig.cas.client.authentication.Saml11AuthenticationFilter > 2. org.jasig.cas.client.validation.Saml11TicketValidationFilter > 3. org.jasig.cas.client.util.HttpServletRequestWrapperFilter > > and they work as expected. With the help of the third of filters > (HttpServletRequestWrapperFilter) a multi-valued attribute USER_ROLE is > interpreted as the privileges of the user and the > HttpServletRequest.isUserInRole() are handled correctly and everything > integrates smoothly, both in terms of authentication and authorization. So > far - so good. > > And now comes the problem. After everything has been done it turned out > that > my web applications need to invoke an EJB3-based service (a remote one), > which has defined some requirements via @RolesAllowed annotation > (javax.annotation.security.RolesAllowed). My question is: what can I do to > propagate what I have in the web tier (principals? security context? > subject?) to the remote service, so that @RolesAllowed({myrole1}) actually > checks against the attributes of the AttributePrincipal of the web app > calling? Let's assume that the service will trust my web apps, it doesn't > have to revalidate the ticket (although I don't mind). Can the > AttributePrincipal (or other necessary security "artifact") be "attached" > to > the remote EJB request and treated correctly in EJB-tier as the source of > identity and privileges. > > I know there is a thing called WebAuthentication in JBoss, but is it a > solution to this problem? At the first glance I see that: > 1. the WebAuthentication/CasLoginModule approach seems to work in the > reserve direction: the login module associated with the EJB service's realm > validates the ticket and produces the Principal which is stored in the > session, while I've been rather thinking of making the EJB module > faithfully > accept the Principal from the web-tier (as I already have it and it has all > the information I need), > 2. the WebAuthenticationFilter supports the AssertionPrincipal created by > CasLoginModule only - the filters mentioned above produce a > AttributePrincipal, > 3. i'm not sure if WebAuthentication/CasLoginModule approach supports the > case of a remote EJB service (works fine for a local one). > On the other hand, if the remote scenario could be implemented with > WebAuthentication/CasLoginModule then I guess it quick to switch existing > and already casified applications to the WebAuthenticationFilter. > > What do you recommend? Which, if any, scenario is possible: the propagation > of Principal from the web-tier or the WebAuthentication/CasLoginModule. > Does > anyone have another idea? I may misunderstand some concepts behind the > WebAuthentication way, because JAAS seems extremely unintuitive to me. Has > anyone had a similar problem? Both clients (web apps) and service will be > deployed on JBoss 7.1.1.Final AS. > > Thanks in advance, best regards, > Maciek > > > > -- > View this message in context: > http://jasig.275507.n4.nabble.com/Casifying-a-web-app-which-invokes-an-EJB-how-to-propagate-Principal-to-a-remote-service-tp4655615.html > Sent from the CAS Users mailing list archive at Nabble.com. > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
