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

[Arnaud Lesueur]

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