allow WS authn by searching for dn by filter, and allowing anonymous or authn search

Michael Bearfoot 4:45 PM[@Erik Coleman|https://internet2.slack.com/team/U7FN1LQLQ] I think we're all in the same OU.
4:47 PM

1. if ldap authn should be used, this is the prefix of the userId when connecting to ldap, e.g. uid=
   ws.authn.ldap.loginDnPrefix =

1. if ldap authn should be used, this is the suffix to the userId when connecting to ldap, e.g. ,ou=users,dc=school,dc=edu
   ws.authn.ldap.loginDnSuffix =[1:37 PM]
   would be the same as breaking apart this:
   [1:38 PM]
   cn=Grouper,ou=Application Services,o=University of Minnesota,c=US
   
   Erik Coleman 4:53 PMRight my prefix is cn= and my suffix is essentially the base DN of where my user objects are, with a comma in front to complete the full DN.
   
   Michael Bearfoot 4:55 PMI have a developer that is saying that All I need to make ldap work is to remove some bad stuff from web.xml.  But that doc I'm reading says you have to configured grouper-ws.properties.  I'm really confused
   
   Erik Coleman 4:56 PMYes rip out the web.xml stuff so that everything passes thru Tomcat to the app, the app will do the authentication.
   
   Michael Bearfoot 4:56 PMyou don't have to configure the app at all?  That's the part that is confusing me...
   
   Erik Coleman 4:57 PMYou do have to configure grouper-ws.properties if you are bypassing Apache and Tomcat authN.
   4:58 PM
   You're deciding which of the three authN mechanisms you want to use, but pick only one!
   
   Michael Bearfoot 4:59 PMAnd that's what I think I want to do.  bypass those and let grouper-ws do it
   
   Carey Black 5:42 PMI have NOT reviewed the auth code/process that is inside Grouper-WS. ( I hope it is a standard, modern, maintained library type thing. But I kind of doubt that it really is all of those things. )However, Tomcat and/or Apache auth tools have a good chance at being those things.
   AND
   By doing the Auth outside of the Grouper-WS app, you can head off "flaws" that might exist in a "pre-auth" state for the request.  Meaning, the thing you trust to do your Auth is critical. The more isolated that Auth layer is ( and the more "in front of your web app" it is ) then you are likely in a better security posture. ( IMHO ) (edited) 
   
   Carey Black 5:51 PMAnd while I am at it... I think the Tomcat layer even offers the idea of multiple paths to authN. ( via "CombinedRealm" REF: https://tomcat.apache.org/tomcat-8.5-doc/config/realm.html )So if you have "humans" and "non-humans" with different auth methods/ldaps/ou's, etc.... then you can configure Tomcat to deal with those complexities. ( And I would imagine that Apache can do that kind of thing too.)Looks like you would need to write your own code to do that directly with Grouper-WS auth. (or maybe ... "Rampart Auth")  But you should endeavor to never write your own encryption or authentication code. 
   !https://a.slack-edge.com/production-standard-emoji-assets/10.2/google-small/1f44d.png!3
    
   
   Erik Coleman 5:55 PMI totally agree with your assessment, however neither Apache nor Tomcat AuthN fulfilled our functional requirements. Since we are using containers in the cloud, there was no easy way to atomize the configuration secrets securely outside of the code. That said we are still falling short, with the previous mentioned limitations.
   8 replies
   Last reply 13 hours agoView thread
   
   Chris Hyzer 10:39 PM"I would recommend having Grouper-WS do it by itself, that's what we do, though a limitation is that it can authenticate to only a single DN path (i.e., the users all have to be in the same OU or container)."  @Erik Coleman  you should be able to set prefix and seffix to blank, and let the user just authenticate with the full dn, then the users dont have to be in the same OU, right?    Does that work for you?
   
   Michael Gettes 10:40 PMwhat would be “best” is to be able to specify a userPrincipalName and then search on that, get the DN, and bind that way.  just sayin….
    
   Chris Hyzer  12 hours ago
   search on that... by cn and a search OU?  @gettes (edited)
   
   Carey Black  3 hours ago
   The value the user supplies should be a variable that is stuffed into an LDAP filter(new config value named findUserFilter) and a Base OU (new config value named findUserBase). If the filter returns 1 and only 1 entity, then that is the DN the user authentication should be attempted against.  ( AKA: The "username" that is sent to the WebServices should not be assumed to be a CN. Just a string that is configured to map to one, or more, attributes in an "authentication" source. )
   
   Carey Black  3 hours ago
   And because some LDAPS would require non-anonymous binds to do the findUserFilter search it may be necessary to also support a service account DN and password to use for that findUser process too.
   !https://a.slack-edge.com/production-standard-emoji-assets/10.2/google-small/1f44d.png!1
    
   
   Chris Hyzer  < 1 minute ago
   this would be easy to do.  however, doesnt get closer to your previous point about security postures and externalizing/standardizing the authn away from the WS.  Should we implement this?    or at least file a jira?