2010-04-12 6 views
9

Google은 매우 큰 웹 기반 서비스 프로젝트를 시작합니다. 우리는 사용할 호스팅 환경을 결정하려고합니다. 우리는 확장 성을 이유로 Google App Engine을 사용하고 서버를 직접 다루지 않아도됩니다.Google App Engine을 사용하여 도메인에 보안 로그인

보안 로그인/등록은 우리 자신의 도메인을 사용하는 것뿐만 아니라 우리에게 매우 중요합니다. 우리의 타겟 고객은 컴퓨터에 능숙하지 않습니다. 따라서 사용자가 OpenID를 사용하여 사이트에 가입 할 필요가 없기를 원하지 않습니다. 우리는 또한 고객이 Google에 가입하도록 강요하고 싶지 않습니다.

내가 볼 수있는 한, 나는 운이 없다. 나는이 질문에 확실한 답을 얻기를 희망한다. 로그인 (OpenID/Google)을 위해 다른 사이트로 고객을 보낼 필요없이 Google 도메인을 통해 액세스 한 Google 사이트의 암호화 된 로그인을 사용할 수 있습니까?

감사합니다.

+0

은 참조 : http://code.google.com/p/googleappengine/issues/detail?id=792 –

+0

단순히 기존 세션 라이브러리와 함께, 다음, 자신의 로그인 시스템을 구현한다. 모든 관습법이 포함되어 있기 때문에 모든 것을 할 수있는 기존의 라이브러리를 찾을 수는 없습니다. –

답변

3

Google App Engine을 사용하여 사용자 자신의 인증/등록 메커니즘을 만들 수 있습니다. 유일한 문제는 Google App Engine이 현재 Google Apps 도메인이 아닌 https://yourid.appspot.com (예 : https://www.foobar.com)을 통해 HTTPS를 지원한다는 것입니다. 그러나 이는 향후 지원을 위해 roadmap 제품에 있습니다 (제 3 자 도메인 용 SSL). 제품 로드맵에는 OAuth & OpenID에 대한 지원 기능이 내장되어 있습니다.

업데이트 : 다른 옵션은 프록시 서버 (예 : mod_proxy가있는 Apache)를 사용하고 도메인을 프록시 서버에 매핑 한 다음 프록시 서버가 HTTP 및 HTTPS 요청을 Google App Engine에 프록시 할 수 있습니다. 요청은 뒤에서 appspot.com 도메인으로 프록시 될 수 있습니다. 나는 실제로 이것을하지 않았지만, 그것이 효과가 있다고 믿는다. 그러나 이렇게하면 프록시 서버에서 단일 실패 지점이 발생하여 Google App Engine의 고 가용성 및 확장 성의 목표를 근본적으로 상실 할 수 있습니다. Google이 제 3 자 도메인이나 OpenID 용 SSL을 지원할 때까지는 단기 솔루션 일 것입니다.

+0

그래, 내가 다른 해결책을 찾기를 바라고있는 이유를 알고있다. 내가 아는 한, 계획은 Windows XP (모든 브라우저)에서 작동하지 않는 TLS SNI를 구현하는 것입니다. 제 생각에는 고객 환경을 제어하지 않는 공개 사이트에 대한 수용 가능한 솔루션이 아닙니다. – mhost

+0

또 다른 옵션은 HTTP 페이지에서 HTTPS URL에 게시하는 것입니다. 이렇게하면 HTML을 보지 않는 한 사용자는 실제로 https://yourid.appspot.com 도메인을 볼 수 없습니다. 나는 이것이 해킹 인 것을 안다. 그러나 그것은 몇몇 시나리오를 위해 충분할지도 모른다. –

+0

OpenID 지원 기능 (제품 로드맵)은 TLS SNI보다 단기적으로 더 나은 솔루션 일 것입니다. 아직 Windows XP를 사용하는 사람들이 너무 많아서 해당 사용자를 지원할 수 없다는 것에 동의합니다. –

6

가장 어려운 부분은 쿠키 문제를 해결하는 것입니다. https://yourdomain.appspot.com에 대한 보안 및 사용자 정의 로그인을 수행 할 수 있지만 http://yourdomain.com에서 작동하는 쿠키는 설정할 수 없습니다.

당신이 사용자가 로그인 할 필요가 그들을 https://yourdomain.appspot.com로 전송 : 여기에

내가 제안하는 것입니다. 자격 증명을 올바르게 입력하면 일회 토큰을 만들어 데이터 스토어 또는 memcache에 배치합니다. 평생에 몇 초만주세요.

그런 다음 사용자를 http://yourdomain.com/authenticate?token=mytoken (분명히 적절한 이름으로 대체)으로 리디렉션하고 토큰이 유효하고 만료되지 않았는지 확인한 다음 모두 지워진 경우 적절한 쿠키를 설정하고 토큰을 만료시킵니다.

나는 그것이 잘 작동한다고 생각합니다. 희망이 도움이됩니다!

+0

열지 않으시겠습니까? 명의 도용까지? 중간 공격을하는 사람을 실행하는 경우 사용자가 토큰을 사용하지 못하도록 막은 다음 사용자가 직접 사용합니다. 이제 사용자로 로그인 했으므로 사용자는 다시 로그인해야합니다. – rhololkeolke

1

위협 모델이 GAE의 "마지막 홉"에서 암호화되지 않은 링크를 허용 할 수 있는지 여부에 따라 프록시를 사용하여 브라우저에서 SSL을 처리 할 수 ​​있습니다. 여기에 내가 SSL 상시 얻을 CloudFlare를 사용하여 최대 쓴 HOWTO는 다음과 같습니다

이 구조적으로 구글이 작동에서하는 방식의 SSL보다 다르지 않다 http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine

, 그것은 구글이 제공하는 SSL이 종료됩니다 단지입니다 G의 네트워크 내에서가 아니라 외부에 있습니다. Firesheep을 보호하려고한다면 CloudFlare (또는 다른 SSL 프록시)가 정상적으로 작동합니다.CF와 Google 간의 트렁크 연결에 대한 걱정이 있다면 더 복잡한 솔루션을 원할 수 있습니다.

관련 문제