You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rupert Whitefield <Ru...@detica.com> on 2008/04/07 19:22:56 UTC

Apache Tomcat role authorisation against AD2003

> All,
> 
> Hoping that someone can help.  Checked google/marc etc.  Similar
> posts, but no solutions??
> 
> Looking to authenticate & authorise Tomcat 5.5.7 against AD 2003.
> 
> Authentication works great.  Authorisation doesn't.  
> 
> Server.xml:
> 
> <Realm   className="org.apache.catalina.realm.JNDIRealm" debug="99"
> 
>      	 connectionURL="ldap://x.x.x.x:yyy"
> 	 connectionName="user@domain"
>       	 connectionPassword="user_password"
>              userBase="cn=xxxxx,dc=xxxxx,dc=xxxxx"
>              userSearch="(sAMAccountName={0})"
>              userSubtree="true"
>              userRoleName="memberOf"
>              roleBase="cn=xxxxx,dc=xxxxx,dc=xxxxx"
>             roleName="cn"
>              roleSubtree="true"
>              roleSearch="(uniqueMember={0})"
> />
> 
> 
> Roles (users windows domain groups) are being returned, however the
> issue is that AD is returning the DN, and not the 'cn'.  Have tried
> various values in the roleName field - but these have no effect.
> 
> I can change the <role-name> definitions in the web.xml files to match
> what is being returned - but this isn't ideal, and I still have issues
> with the ',' in the role when using struts.....
> 
> 
> Logging below shows issue:
> 
> FINE:   Checking roles
> GenericPrincipal[RHWhitefield(CN=group1,CN=xxxx,DC=yyy,DC=zzzz,
> 	
> CN=group2,CN=xxxx,DC=yyy,DC=zzzz,
> 	
> CN=group3,CN=xxxx,DC=yyy,DC=zzzz,
> 	
> CN=group4,CN=xxxx,DC=yyy,DC=zzzz,)]
> 
> I am ideally looking for just the cn or name or sAMAccountName, rather
> than the DN.
> 
> Any guidance would be gratefully appreciated.
> 
> Thanks
> 
> Rupert.
> 



This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.



Re: Apache Tomcat role authorisation against AD2003

Posted by Mark Thomas <ma...@apache.org>.
Rupert Whitefield wrote:
> Hi Mark,
> 
> Thanks for your response on that.  I tested both methods, and still no
> joy.  It is as if IE can't find the main class.  I should have put the
> complete error that I am seeing - it reads "Internet Explorer cannot
> download main from localhost"," Requested site unavailable".  Have used
> FIDDLER HTTP browser to look at the URL which it is requesting looks ok
> (i.e. HTTPS://localhost:8080/marketops/main).  When configured for HTTP
> only, the URL is the same (minus the (S) on HTTP) and it all works ok.
> Nothing logged in HTTP logs.  Thought that it may be related to the JWS
> not being able to find a CERT/keystore?
> 
> Again - Thanks for your time.
> 
> Rupert.

Does HTTPS work at all? What about if you just request a static html page? 
Is this with or without CLIENT-CERT authentication?

Mark

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Apache Tomcat role authorisation against AD2003

Posted by Rupert Whitefield <Ru...@detica.com>.
Hi Mark,

Thanks for your response on that.  I tested both methods, and still no
joy.  It is as if IE can't find the main class.  I should have put the
complete error that I am seeing - it reads "Internet Explorer cannot
download main from localhost"," Requested site unavailable".  Have used
FIDDLER HTTP browser to look at the URL which it is requesting looks ok
(i.e. HTTPS://localhost:8080/marketops/main).  When configured for HTTP
only, the URL is the same (minus the (S) on HTTP) and it all works ok.
Nothing logged in HTTP logs.  Thought that it may be related to the JWS
not being able to find a CERT/keystore?

Again - Thanks for your time.

Rupert.

  

-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org] 
Sent: 11 April 2008 15:01
To: Tomcat Users List
Subject: Re: Apache Tomcat role authorisation against AD2003

Rupert Whitefield wrote:
> So moved onto my next problem, which is why when securing the URL via 
> HTTPS, everything works great , but IE can no longer 'find' the Java 
> Web Start application..... And it worked on same port with HTTP. Sigh.
> Looking into it.

This sounds like the caching problem in IE. Caching has to be disabled
because of the <insert your favourite expletive here> stupid way IE
handles downloads. It downloads them to a temporary location and then
opens them in the specified application or copies them to where the user
specified. IE treats this temporary location as a cache. The problem is
that secure content is marked as non-cacheable so IE obeys this
instruction and deletes it from the temporary location as soon as the
download finishes. This means when the app tries to open the file it
isn't there. The two options to fix this are:

1. disableProxyCaching="false"
Disables all caching. I have concerns about this. As long as there are
no proxies / web caches on the network you should be  fine. If there is
a proxy / cache then you may well hit issues with people being able to
access content they shouldn't.

2. securePagesWithPragma="false"
This only allows caching if the cache is private to the user (as it is
with the IE download 'cache'). This should work and does not present any
issues with web proxies / caches as long as they obey the 'don't put
this in a shared cache' headers (which any off the shelf cache should).

Either of these options can be set on the authenticator. Eg:
<Context>
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator" 
disableProxyCaching="false" />
</Context>

Hope this helps,

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org




This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Apache Tomcat role authorisation against AD2003

Posted by Mark Thomas <ma...@apache.org>.
Rupert Whitefield wrote:
> So moved onto my next problem, which is why when securing the URL via
> HTTPS, everything works great , but IE can no longer 'find' the Java Web
> Start application..... And it worked on same port with HTTP. Sigh.
> Looking into it.

This sounds like the caching problem in IE. Caching has to be disabled 
because of the <insert your favourite expletive here> stupid way IE handles 
downloads. It downloads them to a temporary location and then opens them in 
the specified application or copies them to where the user specified. IE 
treats this temporary location as a cache. The problem is that secure 
content is marked as non-cacheable so IE obeys this instruction and deletes 
it from the temporary location as soon as the download finishes. This means 
when the app tries to open the file it isn't there. The two options to fix 
this are:

1. disableProxyCaching="false"
Disables all caching. I have concerns about this. As long as there are no 
proxies / web caches on the network you should be  fine. If there is a 
proxy / cache then you may well hit issues with people being able to access 
content they shouldn't.

2. securePagesWithPragma="false"
This only allows caching if the cache is private to the user (as it is with 
the IE download 'cache'). This should work and does not present any issues 
with web proxies / caches as long as they obey the 'don't put this in a 
shared cache' headers (which any off the shelf cache should).

Either of these options can be set on the authenticator. Eg:
<Context>
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator" 
disableProxyCaching="false" />
</Context>

Hope this helps,

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Apache Tomcat role authorisation against AD2003

Posted by Rupert Whitefield <Ru...@detica.com>.
Hi Chris,

Thanks for the mail. The only thing that changed in my server.xml was
the order, and changed the roleSearch from:

roleSearch="(uniqueMember={0})

To

roleSearch="(member={0})

Apart from that, I'm a little confused why it works - but it does....

If a user had 3 roles (group1, group2, group3) - (is a member of 3
Windows domain groups) - then I was getting back

CN=CN=group1,CN=xxxx,DC=yyy,DC=zzzz
CN=CN=group2,CN=xxxx,DC=yyy,DC=zzzz
CN=CN=group3,CN=xxxx,DC=yyy,DC=zzzz
group1
group2
group3


So moved onto my next problem, which is why when securing the URL via
HTTPS, everything works great , but IE can no longer 'find' the Java Web
Start application..... And it worked on same port with HTTP. Sigh.
Looking into it.

Rupert.


-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: 09 April 2008 14:16
To: Tomcat Users List
Subject: Re: Apache Tomcat role authorisation against AD2003




This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rupert,

Rupert Whitefield wrote:
| Thanks for the response.  I think you are correct on the role 
| definition (could not find a way of escaping or wildcarding the role 
| which struts
| 1.1 suggests is possible) - so have worked a little more on the AD 
| realm settings in Tomcat.  By trail and error I have found the below
to work:

Your new configuration looks the same as your original configuration to
me. What changed?

| This seems to return both the cn and DN, i.e. really twice as much 
| role data as I need - but at least it works.....

When you say it "returns both", what do you mean? If a user has 3 roles,
for how many different values will request.isUserInRole(value) return
true?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf8wawACgkQ9CaO5/Lv0PD5eACdEuglj6wGsWsvrTPnUmco8lpG
EvgAn1oR4vz/BGrcthNy1G75oS/4c2Ur
=AA/t
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org




This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Apache Tomcat role authorisation against AD2003

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rupert,

Rupert Whitefield wrote:
| Thanks for the response.  I think you are correct on the role definition
| (could not find a way of escaping or wildcarding the role which struts
| 1.1 suggests is possible) - so have worked a little more on the AD realm
| settings in Tomcat.  By trail and error I have found the below to work:

Your new configuration looks the same as your original configuration to
me. What changed?

| This seems to return both the cn and DN, i.e. really twice as much role
| data as I need - but at least it works.....

When you say it "returns both", what do you mean? If a user has 3 roles,
for how many different values will request.isUserInRole(value) return true?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf8wawACgkQ9CaO5/Lv0PD5eACdEuglj6wGsWsvrTPnUmco8lpG
EvgAn1oR4vz/BGrcthNy1G75oS/4c2Ur
=AA/t
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Apache Tomcat role authorisation against AD2003

Posted by Rupert Whitefield <Ru...@detica.com>.
Chris,

Thanks for the response.  I think you are correct on the role definition
(could not find a way of escaping or wildcarding the role which struts
1.1 suggests is possible) - so have worked a little more on the AD realm
settings in Tomcat.  By trail and error I have found the below to work:

<Realm className="org.apache.catalina.realm.JNDIRealm" debug="99"

               connectionURL="ldap://connection_ip:389" 
               connectionName="connection_username"
               connectionPassword="password"      
               userRoleName="memberOf"
               userBase="cn=Users,dc=xxxxxx,dc=yyyyyy"
               userSearch="(sAMAccountName={0})"
               roleBase="cn=Users,dc=xxxxxx,dc=yyyyyy"
               roleName="cn"
               roleSearch="(member={0})"
               roleSubtree="true"
               userSubtree="true" 
 /> 

This seems to return both the cn and DN, i.e. really twice as much role
data as I need - but at least it works.....

Thanks again

Rupert.


-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net] 
Sent: 08 April 2008 15:36
To: Tomcat Users List
Subject: Re: Apache Tomcat role authorisation against AD2003




This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rupert,

Rupert Whitefield wrote:
|> Roles (users windows domain groups) are being returned, however the 
|> issue is that AD is returning the DN, and not the 'cn'.  Have tried 
|> various values in the roleName field - but these have no effect.

Are CNs unique? I would be concerned that cn=admin,dc=admins would be
confused with cn=admin,dc=h4x0r5, if someone got ahold of your AD
server.

|> I can change the <role-name> definitions in the web.xml files to 
|> match what is being returned - but this isn't ideal, and I still have

|> issues with the ',' in the role when using struts.....

Hmm... role-name elements in web.xml must be NMTOKENs, which means:

NameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender
Nmtoken  ::= (NameChar)+

(Where 'Letter' and 'Digit' are obvious)

'Extender' includes the '.' character and a bunch of higher-order
UNICODE characters. 'CombiningChar' also includes higher-order UNICODE
characters. I didn't bother looking any of them up, but you can use this
page for reference: http://www.w3.org/TR/1998/REC-xml-19980210

Perhaps commas are not legal in the role-name in the first place. That
could be a problem :(

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7grUACgkQ9CaO5/Lv0PDcLgCeKw9vFRml1kVxTe0M79uGX+4L
DMkAoI5TRYT8xlZKYjqSqcCJUuGVzG2a
=13Yo
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org




This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory.  The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Apache Tomcat role authorisation against AD2003

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rupert,

Rupert Whitefield wrote:
|> Roles (users windows domain groups) are being returned, however the
|> issue is that AD is returning the DN, and not the 'cn'.  Have tried
|> various values in the roleName field - but these have no effect.

Are CNs unique? I would be concerned that cn=admin,dc=admins would be
confused with cn=admin,dc=h4x0r5, if someone got ahold of your AD server.

|> I can change the <role-name> definitions in the web.xml files to match
|> what is being returned - but this isn't ideal, and I still have issues
|> with the ',' in the role when using struts.....

Hmm... role-name elements in web.xml must be NMTOKENs, which means:

NameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender
Nmtoken  ::= (NameChar)+

(Where 'Letter' and 'Digit' are obvious)

'Extender' includes the '.' character and a bunch of higher-order
UNICODE characters. 'CombiningChar' also includes higher-order UNICODE
characters. I didn't bother looking any of them up, but you can use this
page for reference: http://www.w3.org/TR/1998/REC-xml-19980210

Perhaps commas are not legal in the role-name in the first place. That
could be a problem :(

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf7grUACgkQ9CaO5/Lv0PDcLgCeKw9vFRml1kVxTe0M79uGX+4L
DMkAoI5TRYT8xlZKYjqSqcCJUuGVzG2a
=13Yo
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org