Building a new authentication and authorization strategy
Locked
Building a new authentication and authorization strategy
 
|
Good afternoon,
After a quick 'mvn eclipse:eclipse', I've spent the afternoon digging through the auth/auth code in Nexus. My goal is to implement an authentication and authorization strategy that is backed by Sun's OpenSSO (a.k.a. - Federated Access Manager). From what I can tell of the Nexus design I think this will be possible but I have a few questions: - Do the AccessDecisionVoter implementation instances have access to the User object provided by the AuthenticationSource.authenticate() implementations? OpenSSO authentication provides an opaque token representing the user and my thought was to cache that in the User instance upon authentication and feed it back to the OpenSSO API when asked to authenticate an action. - Do I need to implement AccessManager? It looks like AffirmativeAccessManager is intended to handle most cases so I think the answer is "no". - How do you normally test / develop nexus? I'm using Eclipse and it would be nice if I could launch the server from the IDE. Currently, I'm invoking 'mvn install' at the top level of the trunk then I untar the resulting 'nexus-webapp-1.0.0-beta-4-SNAPSHOT-bundle.tar.gz' but that means I will need to reconfigure for each build/test/debug cycle. I'm sure you're doing something much more efficient... Thanks in advance, James --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Building a new authentication and authorization strategy
|
Hi James,
We are currently working on a new security implementation that is role based. It is in a nexus-security branch in svn. Looking at this may give you some ideas about how to hook in. We use the plx plugin to boot nexus, go to the nexus-webapp folder and run "mvn plx:run" and it should launch nexus. -----Original Message----- From: James CE Johnson [mailto:[hidden email]] Sent: Monday, June 09, 2008 4:45 PM To: [hidden email] Subject: [nexus-dev] Building a new authentication and authorization strategy Good afternoon, After a quick 'mvn eclipse:eclipse', I've spent the afternoon digging through the auth/auth code in Nexus. My goal is to implement an authentication and authorization strategy that is backed by Sun's OpenSSO (a.k.a. - Federated Access Manager). From what I can tell of the Nexus design I think this will be possible but I have a few questions: - Do the AccessDecisionVoter implementation instances have access to the User object provided by the AuthenticationSource.authenticate() implementations? OpenSSO authentication provides an opaque token representing the user and my thought was to cache that in the User instance upon authentication and feed it back to the OpenSSO API when asked to authenticate an action. - Do I need to implement AccessManager? It looks like AffirmativeAccessManager is intended to handle most cases so I think the answer is "no". - How do you normally test / develop nexus? I'm using Eclipse and it would be nice if I could launch the server from the IDE. Currently, I'm invoking 'mvn install' at the top level of the trunk then I untar the resulting 'nexus-webapp-1.0.0-beta-4-SNAPSHOT-bundle.tar.gz' but that means I will need to reconfigure for each build/test/debug cycle. I'm sure you're doing something much more efficient... Thanks in advance, James --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Building a new authentication and authorization strategy
|
|
Hi Brian,
Yes, it looks like I can implement AuthorizationSource without much trouble though 'check(roleName,permission)' may take some thought. I didn't see any references to that other than test cases. Do you expect it to remain in the API? FYI, 'mvn plx:run' was unhappy but 'mvn org.sonatype.plugins:plx-maven-plugin:run' does better but dies with: [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] org/apache/commons/collections/ExtendedProperties [INFO] ------------------------------------------------------------------------ [INFO] Trace java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties at org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:164) at org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:71) at org.sonatype.plexus.classworlds.io.ClassworldsConfWriter.write(ClassworldsConfWriter.java:118) at org.sonatype.plexus.maven.plugin.PlexusRunMojo.writeConfig(PlexusRunMojo.java:344) at org.sonatype.plexus.maven.plugin.PlexusRunMojo.buildCommandLine(PlexusRunMojo.java:230) ... > Hi James, > We are currently working on a new security implementation that is role > based. It is in a nexus-security branch in svn. Looking at this may give > you some ideas about how to hook in. > > We use the plx plugin to boot nexus, go to the nexus-webapp folder and > run "mvn plx:run" and it should launch nexus. > > -----Original Message----- > From: James CE Johnson [mailto:[hidden email]] > Sent: Monday, June 09, 2008 4:45 PM > To: [hidden email] > Subject: [nexus-dev] Building a new authentication and authorization > strategy > > Good afternoon, > > After a quick 'mvn eclipse:eclipse', I've spent the afternoon digging > through the auth/auth code in Nexus. My goal is to implement an > authentication and authorization strategy that is backed by Sun's > OpenSSO > (a.k.a. - Federated Access Manager). From what I can tell of the Nexus > design I think this will be possible but I have a few questions: > > - Do the AccessDecisionVoter implementation instances have access to the > User object provided by the AuthenticationSource.authenticate() > implementations? OpenSSO authentication provides an opaque token > representing the user and my thought was to cache that in the User > instance upon authentication and feed it back to the OpenSSO API when > asked to authenticate an action. > > - Do I need to implement AccessManager? It looks like > AffirmativeAccessManager is intended to handle most cases so I think the > answer is "no". > > - How do you normally test / develop nexus? I'm using Eclipse and it > would > be nice if I could launch the server from the IDE. Currently, I'm > invoking > 'mvn install' at the top level of the trunk then I untar the resulting > 'nexus-webapp-1.0.0-beta-4-SNAPSHOT-bundle.tar.gz' but that means I will > need to reconfigure for each build/test/debug cycle. I'm sure you're > doing > something much more efficient... > > Thanks in advance, > James > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Building a new authentication and authorization strategy
|
James,
for plx plugin you need maven 2.1, it will not work with 2.0.x line.... You can grab a maven 2.1 from ci.sonatype.org or build it yourself. ~t~
On Tue, Jun 10, 2008 at 4:44 PM, James CE Johnson <[hidden email]> wrote: Hi Brian, -- Thanks, ~t~ |
Re: Building a new authentication and authorization strategy
|
|
Today must be Monday...
I can't find a binary at ci.sonatype.org and when I try to build I'm missing a dependency: Missing: ---------- 1) org.apache.xbean:xbean-reflect:jar:3.4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.xbean -DartifactId=xbean-reflect \ -Dversion=3.4-20080418.173627-4 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.maven:maven-workspace:jar:2.1-SNAPSHOT 2) org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-46-SNAPSHOT 3) org.apache.xbean:xbean-reflect:jar:3.4-20080418.173627-4 > James, > > for plx plugin you need maven 2.1, it will not work with 2.0.x line.... > You can grab a maven 2.1 from ci.sonatype.org or build it yourself. > > ~t~ > > On Tue, Jun 10, 2008 at 4:44 PM, James CE Johnson <[hidden email]> wrote: > >> Hi Brian, >> >> Yes, it looks like I can implement AuthorizationSource without much >> trouble though 'check(roleName,permission)' may take some thought. I >> didn't see any references to that other than test cases. Do you expect >> it >> to remain in the API? >> >> FYI, 'mvn plx:run' was unhappy but 'mvn >> org.sonatype.plugins:plx-maven-plugin:run' does better but dies with: >> >> [ERROR] FATAL ERROR >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] org/apache/commons/collections/ExtendedProperties >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Trace >> java.lang.NoClassDefFoundError: >> org/apache/commons/collections/ExtendedProperties >> at >> >> org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:164) >> at >> org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:71) >> at >> >> org.sonatype.plexus.classworlds.io.ClassworldsConfWriter.write(ClassworldsConfWriter.java:118) >> at >> >> org.sonatype.plexus.maven.plugin.PlexusRunMojo.writeConfig(PlexusRunMojo.java:344) >> at >> >> org.sonatype.plexus.maven.plugin.PlexusRunMojo.buildCommandLine(PlexusRunMojo.java:230) >> ... >> >> > Hi James, >> > We are currently working on a new security implementation that is role >> > based. It is in a nexus-security branch in svn. Looking at this may >> give >> > you some ideas about how to hook in. >> > >> > We use the plx plugin to boot nexus, go to the nexus-webapp folder and >> > run "mvn plx:run" and it should launch nexus. >> > >> > -----Original Message----- >> > From: James CE Johnson [mailto:[hidden email]] >> > Sent: Monday, June 09, 2008 4:45 PM >> > To: [hidden email] >> > Subject: [nexus-dev] Building a new authentication and authorization >> > strategy >> > >> > Good afternoon, >> > >> > After a quick 'mvn eclipse:eclipse', I've spent the afternoon digging >> > through the auth/auth code in Nexus. My goal is to implement an >> > authentication and authorization strategy that is backed by Sun's >> > OpenSSO >> > (a.k.a. - Federated Access Manager). From what I can tell of the Nexus >> > design I think this will be possible but I have a few questions: >> > >> > - Do the AccessDecisionVoter implementation instances have access to >> the >> > User object provided by the AuthenticationSource.authenticate() >> > implementations? OpenSSO authentication provides an opaque token >> > representing the user and my thought was to cache that in the User >> > instance upon authentication and feed it back to the OpenSSO API when >> > asked to authenticate an action. >> > >> > - Do I need to implement AccessManager? It looks like >> > AffirmativeAccessManager is intended to handle most cases so I think >> the >> > answer is "no". >> > >> > - How do you normally test / develop nexus? I'm using Eclipse and it >> > would >> > be nice if I could launch the server from the IDE. Currently, I'm >> > invoking >> > 'mvn install' at the top level of the trunk then I untar the resulting >> > 'nexus-webapp-1.0.0-beta-4-SNAPSHOT-bundle.tar.gz' but that means I >> will >> > need to reconfigure for each build/test/debug cycle. I'm sure you're >> > doing >> > something much more efficient... >> > >> > Thanks in advance, >> > James >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [hidden email] >> > For additional commands, e-mail: [hidden email] >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [hidden email] >> > For additional commands, e-mail: [hidden email] >> > >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> > > > -- > Thanks, > ~t~ > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Building a new authentication and authorization strategy
|
James,
the path to (currently) latest build is here: https://ci.sonatype.org/view/Maven%202.1x/job/Maven-2.1.x/ws/maven-2.1.x/maven-distribution/target/ The Job number will change if any SVN change is pulled/detected by Hudson, but the path is generally the same :) ~t~ On Tue, 2008-06-10 at 12:06 -0400, James CE Johnson wrote:
|
Re: Building a new authentication and authorization strategy
|
|
Thanks Tamas! Things are getting better. I have maven 2.1.x installed and
successfully built the nexus-security branch. Now I'm back to trying 'mvn plx:run' in maven-webapp and it's upset about a missing class: --------------------------------------------------- Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties at org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:164) at org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:71) at org.sonatype.plexus.classworlds.io.ClassworldsConfWriter.write(ClassworldsConfWriter.java:118) at org.sonatype.plexus.maven.plugin.PlexusRunMojo.writeConfig(PlexusRunMojo.java:344) at org.sonatype.plexus.maven.plugin.PlexusRunMojo.buildCommandLine(PlexusRunMojo.java:230) at org.sonatype.plexus.maven.plugin.PlexusRunMojo.execute(PlexusRunMojo.java:203) > James, > > the path to (currently) latest build is here: > <a href="https://ci.sonatype.org/view/Maven%">https://ci.sonatype.org/view/Maven% > 202.1x/job/Maven-2.1.x/ws/maven-2.1.x/maven-distribution/target/ > > The Job number will change if any SVN change is pulled/detected by > Hudson, but the path is generally the same :) > > ~t~ --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Building a new authentication and authorization strategy
|
|
James,
this stack trace is the same as it was with 2.0.x.... Are you sure you are using 2.1 for plx plugin? :) mvn -v says it is 2.1? ~t~ On Tue, Jun 10, 2008 at 7:14 PM, James CE Johnson <[hidden email]> wrote: Thanks Tamas! Things are getting better. I have maven 2.1.x installed and -- Thanks, ~t~ |
Re: Building a new authentication and authorization strategy
|
|
> James,
> > this stack trace is the same as it was with 2.0.x.... > > Are you sure you are using 2.1 for plx plugin? :) > > mvn -v says it is 2.1? Yep: $ mvn -v Maven version: 2.1-SNAPSHOT Java version: 1.5.0_07 Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" family: "windows" I even relocated all of my older maven versions so that they can't be picked up by accident. It must have been a bad dependency in my ~/.m2/repository. I relocated that as well then did a 'mvn clean' followed by 'mvn install'. (This is in my sandbox checked out from "http://svn.sonatype.org/nexus/branches/nexus-security" BTW.) 'mvn plx:run' is working now. > > ~t~ > > On Tue, Jun 10, 2008 at 7:14 PM, James CE Johnson <[hidden email]> wrote: > >> Thanks Tamas! Things are getting better. I have maven 2.1.x installed >> and >> successfully built the nexus-security branch. >> >> Now I'm back to trying 'mvn plx:run' in maven-webapp and it's upset >> about >> a missing class: --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Building a new authentication and authorization strategy
|
|
Ok,
i'm glad it worked. But really have no clue about this local repo problem you had.... ~t~ On Tue, Jun 10, 2008 at 9:16 PM, James CE Johnson <[hidden email]> wrote:
-- Thanks, ~t~ |
Re: Building a new authentication and authorization strategy
|
|
In reply to this post by James CE Johnson
Starting a new sub-thread now that you've helped me get to a point where I
can build and execute the nexus-security branch. I believe I have the beginnings of an OpenSSO auth/auth implementation for Nexus but now that I have it wired in I find that it is only invoked for username 'admin'. Digging through the code I find this method in ApplicationBridge: protected NexusAuthenticationGuard protectResource( Class<? extends Resource> targetClass ) { NexusAuthenticationGuard result = new NexusAuthenticationGuard( getContext(), SimpleAuthenticationSource.ADMIN_USERNAME ); result.setNext( targetClass ); return result; } Commenting out the 'SimpleAuthenticationSource.ADMIN_USERNAME' parameter lets my AuthenticationSource see all users but that's clearly not the right way to solve the problem... Also, though my AuthenticationSource.authenticate() returns an OpenSsoUser instance, my AuthorizationSource.check(user,permissions) always receives a SimpleUser instance. Words of wisdom? Thanks, James --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Building a new authentication and authorization strategy
|
On Jun 10, 2008, at 2:16 PM, James CE Johnson wrote:
> Starting a new sub-thread now that you've helped me get to a point > where I > can build and execute the nexus-security branch. > > I believe I have the beginnings of an OpenSSO auth/auth > implementation for > Nexus but now that I have it wired in I find that it is only invoked > for > username 'admin'. Digging through the code I find this method in > ApplicationBridge: > > protected NexusAuthenticationGuard protectResource( Class<? extends > Resource> targetClass ) > { > NexusAuthenticationGuard result = new NexusAuthenticationGuard( > getContext(), > SimpleAuthenticationSource.ADMIN_USERNAME ); > result.setNext( targetClass ); > return result; > } > > Commenting out the 'SimpleAuthenticationSource.ADMIN_USERNAME' > parameter > lets my AuthenticationSource see all users but that's clearly not the > right way to solve the problem... > > Also, though my AuthenticationSource.authenticate() returns an > OpenSsoUser > instance, my AuthorizationSource.check(user,permissions) always > receives a > SimpleUser instance. > > Words of wisdom? I'm not sure I have any advice, but I think I can explain why you aren't getting an OpenSsoUser in the AuthorizationSource call. The following is the authenticate call in NexusAuthenticationGuard: User user = getAuthenticationSource().authenticate( identifier, new String( secret ) ); if ( getAuthenticationSource().isAnynonymousAllowed() ) { return user != null; } else { return user != null && !user.isAnonymous(); } As you can see, no matter what you return from authenticate, the user object is simply checked and then discarded. Later in the guard code a new SimpleUser object is created (assuming the authenticate call passed). I'd guess it was implemented this way due to the structure imposed by the restlet guard class it extends. Maybe whom ever wrote it can give you some insight into why it is written this way and how to preserve the user object instance returned from authenticate. -dain --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: Building a new authentication and authorization strategy
|
|
Hi Dain,
I missed that when I was trolling through the code. After sending the email I got wrapped up in the NEXUS_AUTH_TOKEN_SCHEME check in NexusAuthenticationGuard.authenticate()... (cr.getScheme().getName() always seems to return "HTTP_Basic") svn blame tells me that brianf and cstamas were the last ones in that bit of code you discuss below. Maybe they can shed some light on things for me. I suppose I could have an association of username to OpenSsoUser in my implementation objects but that seems gross. > > I'm not sure I have any advice, but I think I can explain why you > aren't getting an OpenSsoUser in the AuthorizationSource call. The > following is the authenticate call in NexusAuthenticationGuard: > > User user = > getAuthenticationSource().authenticate( identifier, new > String( secret ) ); > > if ( getAuthenticationSource().isAnynonymousAllowed() ) > { > return user != null; > } > else > { > return user != null && !user.isAnonymous(); > } > > > As you can see, no matter what you return from authenticate, the user > object is simply checked and then discarded. Later in the guard code > a new SimpleUser object is created (assuming the authenticate call > passed). I'd guess it was implemented this way due to the structure > imposed by the restlet guard class it extends. Maybe whom ever wrote > it can give you some insight into why it is written this way and how > to preserve the user object instance returned from authenticate. > > -dain > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
«
Return to Nexus Maven Repository Manager Dev List
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |