Please comment on approaches for different authentication mechanisms for internal/external users
Barrow H Kwan
bhkwan at thoughtworks.com
Sun Feb 10 20:34:45 EST 2008
what happen to IP Spoofing ? although that didn't seem to be a big
concern as they will have to authenticate to either SecurID or the other
authentication backend.
I am interested to know what is the security risk for option 1 as I can
see there is no code changes or introduce new code to get this
internal/external authentication working with options 1
=================
Barrow Kwan
ThoughtWorks, Inc.
New from ThoughtWorks: Mingle, an Agile project management application.
Mingle. Project Intelligence. Powerfully Simple.
More at http://studios.thoughtworks.com
"Arnaud Lesueur" <arnaud.lesueur at gmail.com>
Sent by: cas-bounces at tp.its.yale.edu
02/09/08 01:24 AM
Please respond to
Yale CAS mailing list <cas at tp.its.yale.edu>
To
"Yale CAS mailing list" <cas at tp.its.yale.edu>
cc
Subject
Re: Please comment on approaches for different authentication mechanisms
for internal/external users
+1 for this nice architecture
Regards,
-Arnaud
On Feb 6, 2008 4:36 PM, Scott Battaglia <scott.battaglia at gmail.com> wrote:
Perryn,
Option 2 looks like the best choice if you can validate that cookie.
Another choice, if you have the API for authenticating SecurID requests,
is to have a action in the login flow that sends people to one of two
authentication methods based on their IP address (i.e. internal vs.
external).
-Scott
On Feb 4, 2008 9:09 PM, Perryn Fowler <pezlists at gmail.com> wrote:
Hi Guys,
We have a particular problem we would like to solve, and have come up with
some approaches - answers to my questions below, and general comments on
the two approaches would be greatly appreciated.
THE PROBLEM
We have a number of services protected by CAS. Out users access these in
two ways
- from within our internal network
- from an external netwrok.
For users that are coming from an external network, we require that they
must authenticate using an RSA SecurID before accessing anything.
Currently there is no integration between this an CAS, so external users
have to authenticate using their SecurID and then log in again to CAS
using their CAS password.
We would like to make it so that SecurID users do not need to log in
again, while still allowing internal users to log in using just their
password.
APPROACH ONE
There will be two CAS instances ( cas1 and cas2 ).
- cas1 will be configured to accept SecurID credentials and
authenticate with the RAS ACE server using RADIUS
- cas2 will be configured to accept password credentials and
authenticate with our AD server
cas1 will be accessible externally. cas2 will be accessible from
internally.
- for example, cas1 has an internal IP address 10.200.1.1 and an
external IP address 75.40.150.200.
cas2 has an internal IP address 10.200.1.2. (
because cas2 is not accessible from external, so it will not have an
external IP address )
When people hit http://cas.example.com from external, it will resolve the
ip as 75.40.150.200. The firewall will NAT it to 10.200.1.1 and the user
will be required to use RSA for authentication
When people hit http://cas.example.com from internal, it will resolve the
ip as 10.200.1.2 and the user will be required to use AD for
authentication
All our services will be configured to validate tickets with cas2.
cas1 and cas2 are clustered ( or at least replicate their ticket cache).
This way, external users can authenticate against cas1 and then access
services that validate tickets against cas 2
QUESTIONS ABOUT APPROACH ONE
1) I am a bit concerned about the security implications of ticket cache
replication, since it seems to involve spraying TGT information around
using multicast. This worries me because
a) it makes application security very dependant on the network
security, to make sure this information doesnt 'leak'
b) I guess you have to assume you can trust everyone on your internal
network?
This seems like a fairly big issue to me, but It seems that CAS
clustering is quite wide-spread, so perhaps it isn't really such a big
deal?
As an alternative, could we acheive what we want by using a jdbc
based ticket cache, and making both cas servers make secure connections to
it?
2) Would this approach make clustering CAS for reliability or performance
in the future more complicated?
3) Can anyone see other concerns with this approach?
APPROACH TWO
We have a single CAS server.
We leave the SecurID infrastructure as it is, so that external users have
to authenticate using SecurID ( and hence have a rsa-cookie set) before
they can access the CAS server.
The CAS server is configured to
- authenticate using username/password if they are presented,
otherwise
- look for a rsa-cookie and authenticate using that if it is
present
- otherwise show the password login form.
QUESTIONS ABOUT APPROACH TWO
1) I think it should be fairly easy to configure CAS to behave this way?
Or have I missed something?
2) Does anyone actually know how you go about validating the rsa-cookie?
Is it even possible?
3) Can anyone see other concerns with this approach?
TIA
Perryn
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
--
Arnaud Lesueur
LinkedIn: http://www.linkedin.com/in/lesueur
_______________________________________________
Yale CAS mailing list
cas at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080210/11a907eb/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5256 bytes
Desc: S/MIME Cryptographic Signature
Url : http://tp.its.yale.edu/pipermail/cas/attachments/20080210/11a907eb/attachment.bin
More information about the cas
mailing list