Please comment on approaches for different authentication mechanisms for internal/external users

[Perryn Fowler]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080205/4bb14a52/attachment.html