> As Jared said, I would probably implement this as a filter as well. > Here's how I might do it (this is off the top of my head, so if it is > confusing, please let us know). > > 1. Create an implementation of the AuthenticationToken interface that > will hold your Oracle SSO ID (or whatever else comes in the headers). > Maybe call it TrustedAuthenticationToken or > TrustedOracleSsoAuthenticationToken *** Completed ***
> 2. Create a filter that extends > org.apache.shiro.web.filter.authc.AuthenticatingFilter and override > the 'createToken(request,response)' method. In this method, return an > instance of your TrustedAuthenticationToken that you construct based > on the request/response pair. You can look at the existing > org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter source > code to give you ideas - it does very similar things. *** Completed *** 3. In your filter, override the 'onAccessDenied(request,response)' > method to do almost exactly what the BasicHttpAuthenticationFilter > does. In this method you basically determine "should this request > perform a login? If so, call executeLogin(request,response). If not, > prevent the request from going through". See the > BasicHttpAuthenticationFilter's implementation of that method for an > example. *** Completed *** I had to call executeLogin(request, response) regardless here. If I didn't then a method didn't fire on the Realm object I think. I am going to run thru my tests again and document all of this. > 4. Create a TrustedOracleSsoRealm implementation that extends > AuthorizingRealm. In your constructor, automatically call the > following: > > setCredentialsMatcher(new AllowAllCredentialsMatcher()); > setAuthenticationTokenClass(TrustedAuthenticationToken.class); > > The first line ensures that credentials matching won't be performed > when a Realm functions during a login attempt (this is because you > trust that Oracle already performed the login credentials matching on > its side). The second line ensures that the realm won't participate > in any logins except the Oracle-related ones initiated by your filter. *** Completed *** > > (specify this realm in your Shiro SecurityManager config of course - > shiro.ini, spring, etc). How can I set the 'ini' info in the spring config .xml? I swear I saw an example of that somewhere, but now I can't find it. I want to set the cache there. > > 5. In that Realm's doGetAuthenticationInfo implementation, cast the > token argument to your TrustedAuthenticationToken class. Obtain your > oracle SSO token, and from that return the corresponding principals > and credentials (usually in the form of a SimpleAuthenticationInfo or > SimpleAccount instance). *** Completed *** > > 6. You an also implement doGetAuthorizationInfo to obtain > roles/permissions. In this method call the 'getAvailablePrincipal' > method to obtain the first principal in the principal collection > associated with that realm only. This is usually your 'primary > identifier' for that subject, and from it you can obtain the roles and > permissions and return an instance of AuthorizationInfo. Ok. Believe it or not this is all working perfectly up to step 6, but part of that is the design of the database. I'm working with the DBA now in order to fix the issue. The issue is when a user comes to the first page (where they MUST set their 'region' info) there needs to be a sole role just for that - the home page. This is missing. After they set the 'region' info I will notify listeners, but that's all that I have in my head for now. Rather than try the ThreadLocal approch fist, what do you think about attching the 'region' info to the Shiro Session object? Can I obtain the current session for the current user from the Realm to adjust the query executed by the DAO? That seems simple enough. I am almost there!! You have been an amazing help!! > > 7. Optional - enable caching to ensure that authorization lookups and > checks remain efficient. Configure Shiro's securityManager to use a > cacheManager, e.g. in shiro.ini: securityManager.cacheManager = > $myCacheManager > > > Obviously it would be nice if Shiro had an OracleSsoRealm and > corresponding Filter already in place. If you're willing to donate > your implementation to the ASF, we'd appreciate it! Then other people > can benefit from this as well. > > Anyway, I hope that helps - let us know how it goes. > > Best, > > -- > Les Hazlewood > Founder, Katasoft, Inc. > Application Security Products & Professional Apache Shiro Support and Training: > http://www.katasoft.com > > On Fri, Mar 4, 2011 at 10:01 AM, mangelo <[email protected]> wrote: > > I appreciate the help, but I am so lost that I have no idea where to turn. > > > > My scenario is like this: Users are already authenticated and as a result > > their user-id is in the HttpServletRequest header. I thought I was supposed to > > use the Realm to load their roles, permissions, etc, but it looks like some of > > what is in the Realm is duplicated in the AuthenitcatingFilter. > > > > Once I get the Subject loaded up with their roles and permissions all is well > > and good. Why I could not use Spring security is the user is able to change > > their 'region' which comes with it a new set of permissions. I need for Shiro > > to load up these new permissions so that they can be checked for later. > > > > And now, I'm still staring at a blank wall and security was supposed to be > > done this week. > > > > Mike > > > > ------ Original Message ------ > > Received: > > From: "Jared Bunting [via Shiro Developer]" > > <[email protected]> > > To: mangelo <[email protected]> > > Subject: Re: Single Sign On (SSO), Spring, Hibernate Help. > > > >> > >> > >> On 03/04/2011 09:33 AM, mangelo wrote: > >> > I am brand new to Shiro. Just found it last night. I am very encouraged > > from > >> > what I've read so far. My security requirements seem to be too much for > >> > Spring Security. I am confident that Shiro can handle them given the > >> > flexibility. > >> > > >> > The only problem is that I don't know how quite to get started. I've > > found > >> > the Spring samples and how to get set up. My problem is the users of my > > app > >> > are already authenticated by Oracle SSO. The username is in the request > >> > header. > >> > > >> > How do I get it out of the request header and into Shiro? Where would I > > put > >> > such code? > >> > >> This should go into a filter. You likely want to extend > >> AuthenticatingFilter - look at the BasicHttpAuthenticationFilter for an > >> example that uses headers. > >> > >> Basically, your filter should pack up the header value in an > >> AuthenticationToken. Shiro will pass this AuthenticationToken to your > >> Realm. > >> > >> > > >> > I have based my Realm from the SampleRealm class. Should I always return > >> > 'false' from the supports method? Should I return > > SimpleAuthenticationInfo() > >> > with an empty string as the password? > >> > >> I would say yes. In addition, accept the AuthenticationToken type that > >> you created in your filter. > >> > >> > > >> > If there is a more complete example that would help out a lot. I feel > > like > >> > I've hit a brick wall. > >> > > >> > TIA. > >> > > >> > MIke. > >> > > >> > -- > >> > View this message in context: > > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6088874.html > >> > Sent from the Shiro Developer mailing list archive at Nabble.com. > >> > >> > >> > >> > >> _______________________________________________ > >> If you reply to this email, your message will be added to the discussion > > below: > >> > > http://shiro-developer.582600.n2.nabble.com/Single-Sign-On-SSO-Spring-Hibernate-Help-tp6088874p6089122.html > >> > >> To unsubscribe from Single Sign On (SSO), Spring, Hibernate Help., visit > > http://shiro-developer.582600.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6088874&code=bWlrZWFuZ2Vsb0B1c2EubmV0fDYwODg4NzR8LTE1NDY4NDI3NDY=
