Please comment on approaches for different authentication mechanisms for internal/external users
Arnaud Lesueur
arnaud.lesueur at gmail.com
Wed Feb 13 15:36:18 EST 2008
IP Spoofing should be a network concern. This stuff should be dealed by
firewalls and routers.
BTW, if this should be done by the application while the CAS server should
be accessible by two differents network zones they might be also in front
two different reverse proxies (using Apache + mod_jk). In that case, Apache
could handle IP spoofing.
Another point, in option 1, this kind of DNS tuning is not available in all
DNS architecture
Regards,
-Arnaud
On Feb 11, 2008 2:34 AM, Barrow H Kwan <bhkwan at thoughtworks.com> wrote:
>
> 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*<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*<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*<http://10.200.1.1/>and an external IP address
> *75.40.150.200* <http://75.40.150.200/>.
> cas2 has an internal IP address *10.200.1.2*<http://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* <http://cas.example.com/> from
> external, it will resolve the ip as *75.40.150.200*<http://75.40.150.200/>.
> The firewall will NAT it to *10.200.1.1* <http://10.200.1.1/> and the
> user will be required to use RSA for authentication
> When people hit *http://cas.example.com* <http://cas.example.com/> from
> internal, it will resolve the ip as *10.200.1.2* <http://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* <cas at tp.its.yale.edu>*
> **http://tp.its.yale.edu/mailman/listinfo/cas*<http://tp.its.yale.edu/mailman/listinfo/cas>
>
>
>
>
> _______________________________________________
> Yale CAS mailing list*
> **cas at tp.its.yale.edu* <cas at tp.its.yale.edu>*
> **http://tp.its.yale.edu/mailman/listinfo/cas*<http://tp.its.yale.edu/mailman/listinfo/cas>
>
>
>
>
> --
> Arnaud Lesueur
>
> LinkedIn: *http://www.linkedin.com/in/lesueur*<http://www.linkedin.com/in/lesueur> _______________________________________________
>
> 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/20080213/4c1aecb4/attachment.html
More information about the cas
mailing list