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

[Scott Battaglia]

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