无线端安全登录与鉴权一之Kerberos

无线端登录与鉴权是安全登录以及保证用户数据安全的第一步,也是最重要的一步。之前做过一个安全登录与鉴权的方案,借这个机会,系统的思考一下,与大家交流交流

先介绍一下TX系统使用的Kerberos方案,参考了 http://blog.csdn.net/wulantian/article/details/42418231 的文章

一、概念介绍

Kerberos:起源于希腊神话,是一支守护着冥界长着3个头颅的神犬,在keberos Authentication中,Kerberos的3个头颅代表中认证过程中涉及的3方:Client、Server和KDC,而Kerberos的认证过程就是通过这3方协作完成。

KDC:Kerberos Distribution Center,KDC在整个Kerberos Authentication中作为Client和Server共同信任的第三方起着重要的作用,KDC有两个模块,一个是AuthenticationService,鉴权模块,就是用来认证用户身份的,另一个叫GrantingService,授权模块,颁发访问Service的Ticket给客户端;

TGT:Ticket Granting Ticket,获取Ticket的授权,类似股票中的认购证;

Ticket:票据,入场券,访问服务器资源的凭证

MasterKey:主密钥,用户的明文密码经过hash算法后保存在数据库的密码,不可逆;

SessionKey:会话密钥,客户端与服务端通信期间的密钥;

Skdc_client:KDC和Client之间的SessionKey

Skdc_service:KDC和Service之间的SessionKey

Sserver_client:Service和Client之间的SessionKey

二、原理

整个Kerberos是基于ticket(票据的),先借用一个形象的例子解释下原理

Kerberos原理:我(Client)到游乐场去玩,在游乐场的售票处(KDC的AuthenticationService模块)买了一张门票(Ticket),游乐场有很多娱乐项目,像摩天轮啊、过山车、海盗船……等等的,我先排队玩摩天轮(Service),然后到摩天轮的入口处,验票员美女要验我的票,她就拿着我的票到授权服务器(KDC的GrantingService模块)去刷一下,然后滴……学生卡,出来了一个座位号(Ticket),然后就拿着座位号去玩摩天轮(Service),摩天轮的验票员检查我的座位号(Ticket),能过后,我就可以开心地玩过山车了;然后我又来到摩天轮的地方,按照同样的流程去玩……

Kerberos就是实现了这样的一个过程

三、时序图

有一个有意思的地方,TGT本来是应该KDC直接发给Server的,这里KDC交给了Client转发,为什么?因为KDC懒,哈哈……

如果同时发给Client和Server会存在一个先后的问题,必须保证Server在Client之前收到,这个是没办法的,所以比较好的方式是Client带过去

这个是Kerberos最基本的认证方式,叫域内认证模式,这种方式是有点问题的,就是服务器密钥加密的数据直接返回给客户端了,违背了LongTermKey/MasterKey加密的数据不在网上传输的原则,所以有一种改进方案,请看 无线端安全登录与鉴权二

时间: 2024-10-11 06:58:18

无线端安全登录与鉴权一之Kerberos的相关文章

使用网关zuul过滤器登录鉴权

????1.新建一个filter包 ????????filte有很多种 pre.post. ????2.新建一个类LoginFilter,实现ZuulFilter,重写里面的四个方法(可以根据业务建很多个过滤器filter) ????????filterType/filterOrder/shouldFilter/run ????????1).filterType返回过滤器类型,前置类型为return PRE_TYPe,引入类FilterConstants,在类中可以看到各类filter定义 ??

鉴权,开放式授权,单点登陆

鉴权 鉴权(authentication)是指验证用户是否拥有访问系统的权利.传统的鉴权是通过密码来验证的.这种方式的前提是,每个获得密码的用户都已经被授权.在建立用户时,就为此用户分配一个密码,用户的密码可以由管理员指定,也可以由用户自行申请.这种方式的弱点十分明显:一旦密码被偷或用户遗失密码,情况就会十分麻烦,需要管理员对用户密码进行重新修改,而修改密码之前还要人工验证用户的合法身份. 为了克服这种鉴权方式的缺点,需要一个更加可靠的鉴权方式.目前的主流鉴权方式是利用认证授权来验证数字签名的正

开放平台鉴权以及OAuth2.0介绍

OAuth 2.0 协议 OAuth是一个开发标准,允许用户授权第三方网站或应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方网站或分享他们数据的内容. OAuth 2.0不兼容1.0. 协议的参与者 RO (resource owner): 资源所有者,对资源具有授权能力的人. RS (resource server): 资源服务器,它存储资源,并处理对资源的访问请求. Client: 第三方应用,它获得RO的授权后便可以去访问RO的资源. AS (authoriz

apigw鉴权分析(1-4)新浪微博开放平台 - 鉴权分析

一.访问入口 http://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6%E8%AF%B4%E6%98%8E 微博开放接口的调用,如发微博.关注等,都是需要获取用户身份认证的. 目前微博开放平台用户身份鉴权主要采用的是OAuth2.0. 另外,为了方便开发者开发.测试自己的应用,我们还提供了Basic Auth的身份鉴权方式,但Basic Auth仅适用于应用所属的开发者自己调用接口. OAuth2.0概述 OAuth2.0较1

微服务架构中的安全认证与鉴权

转载:http://www.bootdo.com/blog/open/post/125 从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案. 单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大

CDMA鉴权

WCDMA和GSM安全机制比较 GSM的缺陷分以下几点 首先,认证是单向的,只有网络对用户的认证.而没有用户对网络的认证.因此存在安全漏洞.非法设备可以伪装成合法的网络成瘾,欺骗用户,窃取用户信息. 其次,移动台和网络间的大多数信令是非常敏感的,需要得到完整性的保护.在GSM中,没有考虑数据完整性保护的问题,在传输过程中被改也很难发现. 再次,加密不是端到端的.只有在无线信道部分加密,在固定网中没有加密,采用明文传输,给攻击者机会. 3G时代到来,针对GSM安全漏洞,UTMS的安全机制相对完善.

基于token的鉴权机制 — JWT介绍

前言:在实际开发项目中,由于Http是一种无状态的协议,我们想要记录用户的登录状态,或者为用户创建身份认证的凭证,可以使用Session认证机制或者JWT认证机制. 什么是JWT? Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景.JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可

WebAPI常见的鉴权方法,及其适用范围

在谈这个问题之前,我们先来说说在WebAPI中保障接口请求合法性的常见办法: API Key + API Secret cookie-session认证 OAuth JWT 当然还有很多其它的,比如 openid connect (OAuth 2.0协议之上的简单身份层),Basic Auth ,Digest Auth 不一一例举了 1.API Key + API Secret Resource + API Key + API Secret 匹配正确后,才可以访问Resource,通常还会配合时

HTTP基本认证和JWT鉴权

一.HTTP基本认证 Basic Authentication--当浏览器访问使用基本认证的网站的时候, 浏览器会提示你输入用户名和密码. http auth的过程: · 客户端发送http请求 · 服务器发现配置了http auth,于是检查request里面有没有"Authorization"的http header · 如果有,则判断Authorization里面的内容是否在用户列表里面,Authorization header的典型数据为"Authorization: