CN1893352A - 一种因特网协议多媒体子系统的鉴权方法 - Google Patents
一种因特网协议多媒体子系统的鉴权方法 Download PDFInfo
- Publication number
- CN1893352A CN1893352A CNA200510109162XA CN200510109162A CN1893352A CN 1893352 A CN1893352 A CN 1893352A CN A200510109162X A CNA200510109162X A CN A200510109162XA CN 200510109162 A CN200510109162 A CN 200510109162A CN 1893352 A CN1893352 A CN 1893352A
- Authority
- CN
- China
- Prior art keywords
- cscf
- authentication
- message
- information
- hss
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种IP多媒体子系统的鉴权方法，包括：P－CSCF接收到UE发送来的注册报文后，向所确定的CLF查询UE在接入网中的附着信息得到查询结果，并将携带所述查询结果的注册报文发送给I－CSCF；I－CSCF将所述注册报文转发给HSS告知的S－CSCF；S－CSCF根据从HSS获取的鉴权方式，对UE进行鉴权得到鉴权结果，并将所述鉴权结果发送给UE。本发明由业务层的HSS决定用户的鉴权方式，S－CSCF完成鉴权过程，更具合理性。本发明还进一步提供了IMS业务层鉴权和接入层鉴权绑定的鉴权方式和其他鉴权方式相组合的鉴权方法，确保用户在IMS业务层鉴权和接入层鉴权绑定的鉴权方式失败的情况下也能够正确地进行鉴权。
Description
技术领域
本发明涉及因特网协议(IP)多媒体业务子系统(IMS)领域，特别是一种IP多媒体子系统的鉴权方法。
背景技术
在固定下一代(NGN)网络以及移动网络中，通常可以将网络分为接入网络和业务网络。用户通过接入网络运营商的接入网络接入到IP网络上，然后再通过一个或多个业务网络运营商的业务网络享用不同的业务，例如语音、视频、流媒体等业务。
如果接入网络和业务网络不属于同一个运营商时，接入网络对用户的鉴权和业务网络对用户的鉴权是相互独立的。在此种情况下，一个用户若要享用某种业务，通常需要两次鉴权，一次为接入层的鉴权，在通过接入层的鉴权后用户能够接入到NGN网络；另一次为业务层的鉴权，在通过业务层鉴权后用户可以享用该业务网络提供的业务。
如果业务网络和接入网络属于同一个运营商时，或者业务网络运营商和接入网络运营商之间存在某种合作关系时，在某些组网情况下，业务网络运营商可以将业务层的鉴权同接入层的鉴权绑定，即在用户通过接入层鉴权后，就认为该用户是安全的，不再需要进行业务层的鉴权。
在现有的IP多媒体业务子网络(IP Multimedia Core Network Subsystem，IMS)接入层中，一般使用基于IMS认证的密钥协商(AKA)流程实现IMS业务层对用户的鉴权。
参考图1，AKA流程包括以下步骤：
步骤101，用户终端(User Equipment，UE)向代理呼叫会话控制功能实体(Proxy-Call Session Control Function，P-CSCF)发送注册报文Register。
步骤102，P-CSCF作为会话发起协议(Session Initial Protocol，SIP)代理服务器，将UE的注册报文Register转发给询问呼叫会话控制功能实体(Interrogaing-Call Session Control Function，I-CSCF)。
步骤103，I-CSCF跟归属用户服务器(Home Subscribe Server，HSS)之间通过Cx-Selection-Info消息选择相应的服务呼叫会话控制功能实体(Service-Call Session Control Function，S-CSCF)，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤104，I-CSCF将UE的注册报文Register转发给步骤103中所确定S-CSCF。
步骤105，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤106，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤107，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权向量，发送给S-CSCF。
步骤108，S-CSCF根据在步骤107中获得的鉴权向量以及UE的注册报文，判断出该用户需要进行鉴权，然后向I-CSCF发送4xx Auth_Challenge挑战消息，表示需要进行鉴权，并携带有与鉴权相关的信息。其中4xx表示一类错误，xx代表从00～99的一个数字。
步骤109，I-CSCF将所述4xx Auth_Challenge消息发送给P-CSCF。
步骤110，P-CSCF将所述4xx Auth_Challenge消息发送给UE。
步骤111，UE接收到所述4xx Auth_Challenge消息后，重新向P-CSCF发送新的注册报文Register，并且该Register携带有认证参数。
步骤112，P-CSCF将UE的注册报文Register发送给I-CSCF。
步骤113，I-CSCF接收到所述注册报文Register后，与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询用户注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该用户注册报文的S-CSCF。
步骤114，I-CSCF将注册报文Register转发给步骤113确定的S-CSCF。
步骤115，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF。
步骤116，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤117，S-CSCF根据所述用户的签约数据信息和UE注册报文Register中的认证参数，进行鉴权。如果鉴权成功，S-CSCF向I-CSCF发送2xxAuth_OK消息，表示注册成功，其中2xx表示成功相应的消息，xx为00～99的一个数字。如果鉴权失败，则S-CSCF向I-CSCF发送表示鉴权失败的消息。
步骤118，如果鉴权成功，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。如果鉴权失败，则I-CSCF将上述表示鉴权失败的消息发送给P-CSCF。
步骤119，如果鉴权成功，P-CSCF将上述2xx Auth_OK消息发送给UE。如果鉴权失败，则P-CSCF将上述表示鉴权失败的消息发送给UE。
法国电信在电信和互联网融合业务以及高级网络协议六次会议中间会议(TISPAN 6bis)上提出了一种实现IMS业务层鉴权和接入层鉴权绑定的方案。该方案在网络附着子系统(Network Attach Sub System，NASS)中的连接位置功能实体(Connection Location Function，CLF)上保存有UE的IP地址与接入用户标识(subscription-id)的对应关系、以及该UE业务层鉴权和接入层鉴权绑定的绑定标识，其中用户每个连接都有一个接入用户标识。
参考图2，该方案的大致流程如下：
步骤201，UE向P-CSCF发送注册报文Register。
步骤202，P-CSCF根据注册报文的源IP地址向CLF查询UE的附着信息，附着信息中有UE的接入用户标识，及业务层鉴权与接入层绑定的指示。
步骤203，P-CSCF比较UE的接入用户标识和注册报文中鉴权头域中的私有用户标识，如果两者一致，则说明IMS业务层鉴权成功，执行步骤205及其后续步骤，否则鉴权失败执行步骤204向UE发送鉴权失败消息403Forbidden。
步骤205，P-CSCF继续将UE的注册报文Register转发给I-CSCF，报文中携带鉴权是否成功指示。
步骤206，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤207，I-CSCF将注册报文Register发送给步骤206中所确定S-CSCF。
步骤208，S-CSCF确认用户注册成功后，没有再向HSS请求用户的鉴权向量，而是直接和HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行，以及和HSS之间通过Cx-Pull消息下载用户的签约数据。
步骤209，S-CSCF向I-CSCF回2xx消息，表示鉴权成功。
步骤210，I-CSCF将所述2xx鉴权成功消息发送给P-CSCF。
步骤211，P-CSCF将所述2xx鉴权成功消息发送给UE。
上述技术方案中，要求注册消息Register中携带的私有用户标识与用户的接入用户标识一致，即业务层的私有用户标识和接入层的用户标识是同一个标识，但是很多情况下，业务网络运营商和接入网络运营商并不是同一个运营商，强制要求他们使用相同的标识会限制网络应用的灵活性。在网络接入层的附着子系统中指示业务层鉴权和接入层绑定，也是不合理的，应该由业务层中相关设备(如HSS)来指示，接入层网络只负责提供相关信息。由P-CSCF来完成鉴权工作，也是不合理的，合理的方式应是归属地的S-CSCF来完成业务层的鉴权工作，P-CSCF同样只需要负责提供鉴权相关的信息。
即便如此，某些时候由于用户状态的变化，例如在不同的位置采用不同类型的终端，此时会导致采用缺省设置的IP多媒体子系统和接入层绑定的鉴权方式鉴权失败，降低了服务的质量，所以还需要根据HSS中预先设置的鉴权方式对用户采用第二种鉴权方式再次进行鉴权，但是现有技术没有提供相应的方案。
发明内容
有鉴于此，本发明的目的在于提出一种由业务层决定用户鉴权方式的IP多媒体子系统的鉴权方法。
根据上述目的，本发明提供了一种IP多媒体子系统的鉴权方法，该方法包括以下步骤：
A.P-CSCF接收到UE发送来的注册报文后，根据所述注册报文中的信息以及预先设置的注册报文中的信息与CLF的对应关系确定CLF；
B.P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果，并将携带所述查询结果的注册报文发送给I-CSCF；
C.I-CSCF将所述注册报文转发给HSS告知的S-CSCF；
D.S-CSCF根据从HSS获取的鉴权方式，对UE进行鉴权得到鉴权结果，并将所述鉴权结果发送给UE。
在上述技术方案中，步骤D中所述鉴权方式为IMS业务层鉴权和接入层鉴权绑定。
步骤A之前进一步包括：A1.UE向S-CSCF发送注册报文；A2.S-CSCF向HSS请求所述UE的鉴权向量；A3.HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定，并向S-CSCF发送包括所述鉴权方式的消息；A4.S-CSCF向UE发送包括所述鉴权方式的消息；A5.UE接收到所述包括鉴权方式的消息后，向P-CSCF发送新的注册报文；并且，步骤A、步骤B及步骤C中所述的注册报文为所述新的注册报文。
步骤D之前进一步包括：S-CSCF向HSS请求所述UE的鉴权向量；HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定，并向S-CSCF发送包括所述鉴权方式的消息。
步骤A中所述注册报文中的信息为接入运营商标识或所述注册报文源IP地址。
所述注册报文包括接入用户标识；预先在CLF中保存了与所述接入用户标识对应的UE在接入网中的附着信息；步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述接入用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述接入用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
所述注册报文包括私有用户标识；预先在CLF中保存了与所述私有用户标识对应的UE在接入网中的附着信息；步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述私有用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述私有用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
步骤B进一步包括P-CSCF将所收到的注册报文的源IP地址发送给I-CSCF的步骤；步骤C进一步包括I-CSCF将所述注册报文源IP地址转发给所述S-CSCF的步骤；步骤D中所述对UE进行鉴权得到鉴权结果的步骤包括：在所述查询结果包括IP地址信息时，S-CSCF比较所述P-CSCF所收到的注册报文源IP源地址与所述查询结果中的IP地址信息，如果一致，则得到鉴权成功的鉴权结果，否则得到鉴权失败的鉴权结果；在所述查询结果为查询失败信息时，S-CSCF得到鉴权失败的鉴权结果。
预先在CLF中保存了与注册报文源IP地址对应的UE在接入网中的附着信息；步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述注册报文源IP地址向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述注册报文源IP地址对应的接入用户关联信息的附着信息时，CLF向P-CSCF返回包括所述接入用户关联信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
步骤D中所述对UE进行鉴权得到鉴权结果之前进一步包括S-CSCF从HSS获得预先保存在HSS的绑定的接入用户关联信息的步骤；步骤D中所述对UE进行鉴权得到鉴权结果的步骤包括：在所述查询结果包括接入用户关联信息时，S-CSCF比较所述从HSS获得的绑定的接入用户关联信息与所述查询结果中的接入用户关联信息，如果一致，则得到鉴权成功的鉴权结果，否则得到鉴权失败的鉴权结果；在所述查询结果为查询失败信息时，S-CSCF得到鉴权失败的鉴权结果。
所述接入用户关联信息为接入用户标识、位置信息或IP地址信息。
在上述技术方案中，步骤D中所述鉴权方式为：先采用IMS业务层鉴权和接入层鉴权绑定的鉴权方式，在IMS业务层鉴权和接入层鉴权绑定的鉴权方式进行鉴权失败之后再采用第二鉴权方式；步骤D包括：S-CSCF保存从HSS获取的IMS业务层鉴权和接入层鉴权绑定的鉴权方式以及相应的鉴权参数，以及第二种鉴权方式以及相应的鉴权参数，S-CSCF首先采用IMS业务层鉴权和接入层鉴权绑定的方式，对UE进行鉴权得到鉴权结果，在鉴权结果为成功时，将该鉴权结果发送给UE；在鉴权结果为失败时，再采用第二鉴权方式对UE进行鉴权得到鉴权结果，并将该鉴权结果发送给UE。
较佳地，所述第二鉴权方式为HTTP DIGEST方式。
步骤D中所述采用HTTP DIGEST鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：D11.S-CSCF向UE发送包括所述HTTP DIGEST鉴权方式的挑战消息；D 12.UE接收到所述包括HTTPDIGEST鉴权方式的挑战消息后，向S-CSCF发送包含认证参数的注册消息；D13.S-CSCF执行HTTP DIGEST的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
较佳地，所述第二鉴权方式为IMS AKA方式。
步骤D中所述采用IMS AKA鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：D21.S-CSCF向UE发送包括所述IMSAKA鉴权方式的挑战消息；D22.UE接收到所述包括IMS AKA鉴权方式的挑战消息后，向S-CSCF发送包括认证参数的注册消息；D23.S-CSCF执行IMS AKA的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
步骤A中所述注册报文中的信息为接入运营商标识；所述注册报文包括接入用户标识；预先在CLF中保存了与所述接入用户标识对应的UE在接入网中的附着信息；步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述接入用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述接入用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
步骤A之前进一步包括：A1.UE向S-CSCF发送注册报文；A2.S-CSCF向HSS请求所述UE的鉴权向量；A3.HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方式是先采用IMS业务层鉴权和接入层鉴权绑定的鉴权方式，在IMS业务层鉴权和接入层鉴权绑定的鉴权方式进行鉴权失败之后再采用第二鉴权方式；A4.S-CSCF向UE发送包括所述鉴权方式的消息；A5.UE接收到所述包括鉴权方式的消息后，向P-CSCF发送新的注册报文；并且，步骤A、步骤B及步骤C中所述的注册报文为所述新的注册报文。
在上述方案中，步骤D中所述鉴权方式为：HSS在设置第二鉴权方式时，同时嵌套设置“是否支持IMS业务层和接入层绑定鉴权”标志；步骤D包括：S-CSCF收到HSS发送来的第二鉴权方式，以及同时包括“是否支持IMS业务层和接入层绑定鉴权”标志的鉴权方式；当所述标志表示支持IMS业务层鉴权和接入层鉴权绑定的鉴权方式时，S-CSCF首先保存从HSS获取的第二鉴权方式以及相应的鉴权参数，然后采用IMS业务层鉴权和接入层鉴权绑定的方式，对UE进行鉴权得到鉴权结果，在鉴权结果为成功时，将该鉴权结果发送给UE；在鉴权结果为失败时，再采用第二鉴权方式对UE进行鉴权得到鉴权结果，并将该鉴权结果发送给UE；当所述标志表示不支持IMS业务层鉴权和接入层鉴权绑定的鉴权方式时，S-CSCF直接采用第二鉴权方式对UE进行鉴权得到鉴权结果，并将该鉴权结果发送给UE。
较佳地，所述第二鉴权方式为HTTP DIGEST方式。
步骤D中所述采用HTTP DIGEST鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：D11.S-CSCF向UE发送包括所述HTTP DIGEST鉴权方式的挑战消息；D12.UE接收到所述包括HTTPDIGEST鉴权方式的挑战消息后，向S-CSCF发送包含认证参数的注册消息；D13.S-CSCF执行HTTP DIGEST的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
较佳地，所述第二鉴权方式为IMS AKA方式。
步骤D中所述采用IMS AKA鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：D21.S-CSCF向UE发送包括所述IMSAKA鉴权方式的挑战消息；D22.UE接收到所述包括IMS AKA鉴权方式的挑战消息后，向S-CSCF发送包括认证参数的注册消息；D23.S-CSCF执行IMS AKA的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
步骤A中所述注册报文中的信息为接入运营商标识；所述注册报文包括接入用户标识；预先在CLF中保存了与所述接入用户标识对应的UE在接入网中的附着信息；步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述接入用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述接入用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
从上述方案中可以看出，本发明通过接入用户标识、私有用户标识或注册报文源IP地址查询CLF中的附着信息，并且由HSS决定用户的鉴权方式，以及由S-CSCF进行鉴权成功与否的判断。与现有技术不同，本发明与现有技术相比，由业务层的HSS决定用户的鉴权方式，由S-CSCF完成鉴权过程，更具有合理性。并且，本发明根据接入运营商标识定位CLF，并采用接入用户标识向CLF查询用户附着信息，此时不要求业务层用户标识和接入用户标识一定相同。同时考虑到实际组网的情况，简化方案，本方案同样支持当业务运营商和接入运营商为同一个运营商且IP地址得到较好的规划、业务层私有用户标识和接入用户标识为同一个时，可以用注册报文源IP地址来定位CLF，用业务层私有用户标识或注册报文源IP地址去CLF查询用户在接入网络的附着信息。并且，在S-CSCF鉴权的时候，通过比较从CLF查询得到的IP地址信息与P-CSCF所接收的注册报文的源IP地址、或者比较从CLF查询得到的接入用户关联信息与从HSS获得的绑定的接入用户关联信息，在两者一致的时候得到鉴权成功的结果，在两者不一致的时候得到鉴权失败的结果。因此本方案与现有技术相比更具有通用性和灵活性，在方案上符合业务层鉴权的原则，实现方式更合理、更具有逻辑性，另外本发明的技术方案对现有IMS AKA流程的改动较小，流程基本一致，只是认证参数的变化，和现有IMS AKA的流程更容易融合，具有容易实现的优点。
另外，某些时候根据HSS中预先配置的鉴权方式，本发明在上述IMS业务层鉴权和接入层鉴权绑定的方式鉴权失败以后，还可能进一步采用超文本传输协议摘要(HTTP DIGEST)方式或IMS AKA方式进行鉴权，从而向用户提供多种组合的鉴权方式。
附图说明
图1为AKA鉴权机制的流程示意图；
图2为现有技术的流程示意图；
图3a和图3b为本发明第一实施例的流程示意图；
图4a和图4b为本发明第二实施例的流程示意图；
图5a和图5b为本发明第三实施例的流程示意图；
图6a和图6b为本发明第四实施例的流程示意图；
图7a和图7b为本发明第五实施例的流程示意图；
图8为HTTP DIGEST鉴权机制的流程示意图；
图9a和图9b为本发明第六实施例的流程示意图；
图10a和图10b为本发明第七实施例的流程示意图；
图11a和图11b为本发明第八实施例的流程示意图；
图12a和图12b为本发明第九实施例的流程示意图；
图13a、图13b和图13c为本发明第十实施例的流程示意图；
图14a、图14b和图14c为本发明第十一实施例的流程示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，以下举实施例对本发明进一步详细说明。
本发明的第一实施例以AKA流程为基础，给出了一种IMS业务层鉴权和接入层鉴权绑定的方法。第一实施例中，预先在HSS保存用户的鉴权签约数据，鉴权签约数据表明该用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参考图3a和图3b，第一实施例的流程如下：
步骤301，UE向P-CSCF发送注册报文Register。
步骤302，P-CSCF将UE的注册报文Register转发给I-CSCF。
步骤303，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤304，I-CSCF将UE的注册报文Register转发给步骤303中所确定S-CSCF。
步骤305，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤306，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤307，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定。
步骤308，HSS向S-CSCF发送AV-Req-Resp消息，与现有技术中发送的鉴权向量不同，本步骤里将该用户的鉴权方式信息和鉴权参数发送给S-CSCF。
步骤309，S-CSCF根据在步骤308中获得的鉴权方式信息，得知该用户的鉴权方式是业务层鉴权和接入层鉴权绑定，然后向I-CSCF发送4xxAuth_Challenge消息，并在消息的鉴权头域中表明鉴权方式是业务层鉴权和接入层鉴权绑定，即携带鉴权方式指示信息。
步骤310，I-CSCF将所述携带鉴权方式指示信息的4xx Auth_Challenge消息发送给P-CSCF。
步骤311，P-CSCF接收到所述4xx Auth_Challenge消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将所述携带鉴权方式指示信息的4xxAuth_Challenge消息发送给UE，其中不携带Security-Server头。
步骤312，UE接收到所述4xx Auth_Challenge消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤313，P-CSCF根据注册报文中的运营商标识以及预先设置的运营商标识与CLF之间的对应关系确定CLF。
步骤314，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。与现有技术不同的是，CLF中预先保存了与接入用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤315，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤316，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤317，I-CSCF将包含查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址转发给步骤316确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤318，在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤319及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤331及其后续步骤，即向UE发送鉴权失败的消息。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤331及其后续步骤，即向UE发送鉴权失败的消息。
步骤319，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤320，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤321，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤322，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤323，P-CSCF将上述2xx Auth_OK消息发送给UE。
如图3b所示的步骤331，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤332，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤333，S-CSCF向I-CSCF发送鉴权失败的消息，表示鉴权失败。
步骤334，I-CSCF将上述鉴权失败的消息发送给P-CSCF。
步骤335，P-CSCF将上述鉴权失败的消息发送给UE。
当接入网络运营商和业务网络运营商是同一个运营商时，由于接入用户标识和私有用户标识是相同的，NASS中不会下发接入运营商标识和接入用户标识给UE，可以采用如图4a和图4b所示的第二实施例的方法，第二实施例为第一实施例的简化方式，在第二实施例中，通过Register的源IP地址识别接入运营商及CLF，并且根据IMS业务层的私有用户标识在CLF查询UE在接入层的附着信息。与第一实施例一样，预先在HSS保存用户的鉴权签约数据，鉴权签约数据表明该用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参照图4a和图4b，第二实施例包括以下步骤：
其中，步骤401至步骤411与第一实施例中的步骤301至步骤311相同。
步骤401，UE向P-CSCF发送注册报文Register。
步骤402，P-CSCF将UE的注册报文Register转发给I-CSCF。
步骤403，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤404，I-CSCF将UE的注册报文Register转发给步骤403中所确定S-CSCF。
步骤405，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤406，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤407，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定。
步骤408，HSS向S-CSCF发送AV-Req-Resp消息，与现有技术中发送的鉴权向量不同，本步骤里将该用户的鉴权方式信息和鉴权参数发送给S-CSCF。
步骤409，S-CSCF根据在步骤408中获得的鉴权方式信息，得知该用户的鉴权方式是业务层鉴权和接入层鉴权绑定，然后向I-CSCF发送4xxAuth_Challenge消息，并在消息的鉴权头域中表明鉴权方式是业务层鉴权和接入层鉴权绑定，即携带鉴权方式指示信息。
步骤410，I-CSCF将所述携带鉴权方式指示信息的4xx Auth_Challenge消息发送给P-CSCF。
步骤411，P-CSCF接收到所述4xx Auth_Challenge消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将所述携带鉴权方式指示信息的4xxAuth_Challenge消息发送给UE，其中不携带Security-Server头。
步骤412，UE接收到所述4xx Auth_Challenge消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，与第一实施例不同的是，该报文不需要携带接入运营商标识及接入用户标识，而是采用鉴权头域中携带现有技术中所述的私有用户标识，该标识在现有的IMS AKA流程中已有。
步骤413，P-CSCF根据注册报文的源IP地址以及预先设置的源IP地址与CLF之间的对应关系确定CLF。
步骤414，P-CSCF根据注册报文鉴权头域中的私有用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该私有用户标识的数据记录，CLF会返回查询失败。
以下的步骤415至步骤423与第一实施例中的步骤315至步骤323相同。
步骤415，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤416，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤417，I-CSCF将包含查询结果的注册报文Register以及P-CSCF所接收的Register源IP地址转发给步骤416确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤418，在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤419及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤431及其后续步骤，即向UE发送鉴权失败的消息。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤331及其后续步骤，即向UE发送鉴权失败的消息。
步骤419，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤420，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤421，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤422，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤423，P-CSCF将上述2xx Auth_OK消息发送给UE。
如图4b所示的步骤431，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤432，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤433，S-CSCF向I-CSCF发送鉴权失败的消息，表示鉴权失败。
步骤434，I-CSCF将上述鉴权失败的消息发送给P-CSCF。
步骤435，P-CSCF将上述鉴权失败的消息发送给UE。
在第一实施例和第二实施例的方法中，UE在得到鉴权方式为业务层鉴权与接入层鉴权绑定后，才发送携带运营商标识和接入用户标识的注册报文。在本发明的第三实施例中，UE一开始就发送携带运营商标识和接入用户标识的注册报文。与第一实施例、第二实施例一样，第三实施例中预先在HSS保存用户的鉴权签约数据，鉴权签约数据表明该用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参考图5a和图5b，第三实施例的流程如下：
步骤501，UE向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤502，P-CSCF根据注册报文中的接入运营商标识以及预先设置的接入运营商标识与CLF之间的对应关系确定CLF。
步骤503，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤504，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该注册报文源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤505，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤506，I-CSCF将包括上述查询结果的注册报文Register以及P-CSCF所接收的注册报文源IP地址转发给步骤505确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤507，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤508，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤509，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定。
步骤510，HSS向S-CSCF发送AV-Req-Resp消息，与现有技术中发送的鉴权向量不同，本步骤里将该用户的鉴权方式信息和鉴权参数发送给S-CSCF。
步骤511，在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤512及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤521及其后续步骤，即向UE发送鉴权失败的消息。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤521及其后续步骤，即向UE发送鉴权失败的消息。
步骤512，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤513，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤514，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤515，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤516，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此也不需要建立和P-CSCF之间的安全联盟。
如图5b所示的步骤521，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤522，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤523，S-CSCF向I-CSCF发送鉴权失败的消息，表示鉴权失败。
步骤524，I-CSCF将上述鉴权失败的消息发送给P-CSCF。
步骤525，P-CSCF将上述鉴权失败的消息发送给UE。
与第二实施例一样，当接入网络运营商和业务网络运营商是同一个运营商时，由于接入用户标识和私有用户标识是相同的，NASS中不会下发接入运营商标识和接入用户标识给UE，可以采用如图6a和图6b所示的第四实施例的方法，第四实施例为第三实施例的简化方式，在第四实施例中，通过Register的源IP地址识别接入运营商及CLF，并且根据IMS业务层的私有用户标识在CLF查询UE在接入层的附着信息。与第一实施例一样，预先在HSS保存用户的鉴权签约数据，鉴权签约数据表明该用户的鉴权方式是否为业务层鉴权与接入层鉴权绑定。
参考图6a和图6b，第四实施例包括以下步骤：
步骤601，UE向P-CSCF发送注册报文Register，与第三实施例不同的是，该报文不需要携带接入运营商标识及接入用户标识，而是在鉴权头域中携带现有技术中所述的私有用户标识。
步骤602，P-CSCF根据注册报文的源IP地址以及预先设置的源IP地址与CLF之间的对应关系确定CLF。
步骤603，P-CSCF根据注册报文鉴权头域中的私有用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该私有用户标识的数据记录，CLF会返回查询失败。
以下的步骤604至步骤625与第三实施例中的步骤504至步骤525相同。
步骤604，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该注册报文源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤605，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤606，I-CSCF将包括上述查询结果的注册报文Register以及所述P-CSCF所接收的该注册报文源IP地址转发给步骤605确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤607，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤608，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤609，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定。
步骤610，HSS向S-CSCF发送AV-Req-Resp消息，与现有技术中发送的鉴权向量不同，本步骤里将该用户的鉴权方式信息和鉴权参数发送给S-CSCF。
步骤611，在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤612及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤521及其后续步骤，即向UE发送鉴权失败的消息。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤621及其后续步骤，即向UE发送鉴权失败的消息。
步骤612，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤613，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤614，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤615，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤616，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此也不需要建立和P-CSCF之间的安全联盟。
如图6b所示的步骤621，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤622，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤623，S-CSCF向I-CSCF发送鉴权失败的消息，表示鉴权失败。
步骤624，I-CSCF将上述鉴权失败的消息发送给P-CSCF。
步骤625，P-CSCF将上述鉴权失败的消息发送给UE。
在第一实施例至第四实施例的方法中，S-CSCF通过比较P-CSCF所收到的注册报文Register的源IP地址与从CLF查询得到的IP地址信息是否一致来进行鉴权，在本发明的第五实施例中，S-CSCF通过比较预先保存在HSS的绑定的接入用户关联信息和从CLF查询得到的接入用户关联信息来进行鉴权，其中所述接入用户关联信息可以是接入用户标识(access useridentity)、位置信息(location information)、IP地址信息等，这里以接入用户标识为例说明实现过程。第五实施例中，以注册报文源IP地址为例说明确定CLF以及从CLF查询用户关联信息的过程，但是从前面的实施例能够看出，可以使用其他参数实现这一过程，这里不再赘述。
参考图7a和图7b，第五实施例的流程如下：
步骤701，UE向P-CSCF发送注册报文Register。
步骤702，P-CSCF根据注册报文的源IP地址以及预先设置的IP地址与CLF之间的对应关系确定CLF。
步骤703，P-CSCF根据注册报文的源IP地址，在上面确定的CLF中查询用户的接入用户标识。CLF中预先保存了与源IP地址对应的UE的附着信息的数据记录。所述附着信息至少包括接入用户关联信息，这里接入用户关联信息为接入用户标识。如果CLF中没有该源IP地址的数据记录，CLF会返回查询失败。
步骤704，P-CSCF将携带上一步骤中查询结果的注册报文Register发送给I-CSCF。如果前面的查询成功，则将查询得到的接入用户标识作为查询结果发送给I-CSCF；如果查询失败，则将查询失败信息作为查询结果上报给I-CSCF。
步骤705，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的该UE的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤706，I-CSCF将包括上述查询结果的注册报文Register转发给步骤705确定的S-CSCF。所述查询结果，在查询成功时为查询得到的接入用户标识，在查询失败时为上报的查询失败信息。
步骤707，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤708，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤709，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定。
步骤710，HSS向S-CSCF发送AV-Req-Resp消息，与现有技术中发送的鉴权向量不同，本步骤里将该用户的鉴权方式信息以及接入用户标识下发给S-CSCF。
步骤711，在查询结果为查询得到的接入用户标识时，S-CSCF判断所述从CLF查询得到的接入用户标识与HSS下发的接入用户标识是否一致，如果一致，则说明鉴权成功，执行步骤712及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤521及其后续步骤，即向UE发送鉴权失败的消息。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤721及其后续步骤，即向UE发送鉴权失败的消息。
步骤712，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤713，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤714，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤715，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤716，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此也不需要建立和P-CSCF之间的安全联盟。
如图7b所示的步骤721，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤722，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤723，S-CSCF向I-CSCF发送鉴权失败的消息，表示鉴权失败。
步骤724，I-CSCF将上述鉴权失败的消息发送给P-CSCF。
步骤725，P-CSCF将上述鉴权失败的消息发送给UE。
在以上的实施例中，HSS仅为同一个用户保存一种鉴权方式，即IMS业务层鉴权与接入层鉴权绑定的方式，在上述各种方案中，如果鉴权失败，将会拒绝用户访问网络，这将限制某些时候用户在游牧时的鉴权以及使用网络业务。上述游牧是指用户在移动时能改变其网络接入点，但正在进行的服务会话会完全停止，需要重新启动。
例如，用户可能希望在固定的位置使用传统的终端访问网络，采用“IMS业务层鉴权和接入层鉴权绑定”方式来鉴权用户。当游牧到外地时，希望使用其他终端来访问网络。由于此时用户的位置信息发生了变化，如果仍然采用“IMS业务层鉴权和接入层鉴权绑定”方式，则用户鉴权会失败，从而影响用户对网络的使用。因此，本发明进一步提出了在采用IMS业务层鉴权和接入层鉴权绑定的鉴权失败之后，再采用超文本传输协议摘要(“HTTPDIGEST”)或者“IMS AKA”方式进行鉴权，从而可以为用户提供灵活的鉴权支持。
参考图8，“HTTP DIGEST”鉴权机制的流程大致如下：
步骤801，UE向P-CSCF发送注册报文Register。
步骤802，P-CSCF将UE的注册报文Register转发给I-CSCF。
步骤803，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤804，I-CSCF将UE的注册报文Register转发给步骤803中所确定S-CSCF。
步骤805，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤806，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤807，HSS检查用户的鉴权签约数据，根据鉴权签约数据得到该用户的鉴权方式是“HTTP DIGEST”，并产生例如nonce等鉴权向量以及期望响应(XRES)等等。
然后HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息“HTTP DIGEST”以及鉴权参数nonce、期望响应(XRES)等发送给S-CSCF。
步骤808，S-CSCF得到鉴权方式信息并保存XRES，然后向I-CSCF发送“4xx Auth_Challenge”消息。
步骤809，I-CSCF将“4xx Auth_Challenge”消息发送给P-CSCF。
步骤810，P-CSCF接收到“4xx Auth_Challenge”消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将“4xx Auth_Challenge”消息发送给UE，其中不携带Security-Server头。
步骤811，UE接收到“4xx Auth_Challenge”消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，并携带用于鉴权的响应(RES)。
步骤812，P-CSCF将携带注册报文Register发送给I-CSCF。
步骤813，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。在以下步骤中，S-CSCF将鉴权成功或鉴权失败的消息发送给UE。
步骤814，I-CSCF将注册报文Register转发给步骤813确定的S-CSCF。
此后，S-CSCF比较从HSS获得的XRES和UE发送过来的RES，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤815，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤816，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤817，S-CSCF向I-CSCF发送表示鉴权成功的200消息，或者表示鉴权失败的403Forbidden消息。在图中仅以鉴权成功时的200消息表示。
步骤818，I-CSCF将上述消息发送给P-CSCF。
步骤819，P-CSCF将上述消息发送给UE。
针对前面的第一至第五实施例，本发明进一步在HSS上预先保存的用户鉴权方式为：IMS业务层鉴权和接入层鉴权绑定，失败之后转用“HTTPDIGEST”鉴权方式或“IMS AKA”鉴权方式。
图9a和9b所示的第六实施例针对的是第三实施例，采用IMS业务层鉴权和接入层鉴权绑定方式失败之后再采用“HTTP DIGEST”鉴权方式进行鉴权。
参考图9a和图9b，本发明的第六实施例包括以下步骤：
步骤901，UE向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤902，P-CSCF根据注册报文中的接入运营商标识以及预先设置的接入运营商标识与CLF之间的对应关系确定CLF。
步骤903，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤904，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该注册报文源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤905，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤906，I-CSCF将包括上述查询结果的注册报文Register以及P-CSCF所接收的注册报文源IP地址转发给步骤905确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤907，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤908，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤909，HSS检查用户的鉴权签约数据，根据鉴权签约数据得到该用户的鉴权方式默认为IMS业务层鉴权与接入层鉴权绑定，失败之后再采用“HTTP DIGEST”鉴权方式。
步骤910，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF。
步骤911，S-CSCF保存所有的鉴权方式以及相应的鉴权向量。在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤912及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤921及其后续步骤，即再采用“HTTP DIGEST”鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤921及其后续步骤，即再采用“HTTP DIGEST”鉴权方式进行鉴权。
步骤912，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤913，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤914，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤915，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤916，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。
UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xxAuth_Challenge，因此也不需要建立和P-CSCF之间的安全联盟。
如图9b所示的步骤921，S-CSCF在步骤911中已经保存了从HSS获取的HTTP DIGEST鉴权向量。S-CSCF向I-CSCF发送包括HTTP DIGEST鉴权信息的“4xx Auth_Challenge”消息。
步骤922，I-CSCF将“4xx Auth_Challenge”消息发送给P-CSCF。
步骤923，P-CSCF接收到“4xx Auth_Challenge”消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将“4xx Auth_Challenge”消息发送给UE，其中不携带Security-Server头。
步骤924，UE接收到“4xx Auth_Challenge”消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，并携带用于鉴权的认证参数。
步骤925，P-CSCF将携带认证参数Register发送给I-CSCF。
步骤926，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤927，I-CSCF将注册报文Register转发给步骤926确定的S-CSCF。
此后，S-CSCF比较以前保存的从HSS获得的认证参数和UE发送过来的认证参数，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤928，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤929，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤930，S-CSCF向I-CSCF发送表示鉴权成功的200消息，或者表示鉴权失败的消息。在图中仅以鉴权成功时的200消息表示。
步骤931，I-CSCF将上述消息发送给P-CSCF。
步骤932，P-CSCF将上述消息发送给UE。
如果是针对第四实施例或第五实施例，可以根据第四实施例或第五实施例与第三实施例的不同之处对本实施例作相应的改动，这里不再赘述。
图10a和10b所示的第七实施例针对的是第三实施例，采用IMS业务层鉴权和接入层鉴权绑定方式失败之后再采用“IMS AKA”鉴权方式进行鉴权。
参考图10a和图10b，本发明的第七实施例包括以下步骤：
步骤1001，UE向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤1002，P-CSCF根据注册报文中的接入运营商标识以及预先设置的接入运营商标识与CLF之间的对应关系确定CLF。
步骤1003，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤1004，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该注册报文源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤1005，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤1006，I-CSCF将包括上述查询结果的注册报文Register以及P-CSCF所接收的注册报文源IP地址转发给步骤1005确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤1007，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1008，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤1009，HSS检查用户的鉴权签约数据，根据鉴权签约数据得到该用户的鉴权方式默认为IMS业务层鉴权与接入层鉴权绑定，失败之后再采用“IMS AKA”鉴权方式。
步骤1010，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF。
步骤1011，S-CSCF保存所有的鉴权方式以及相应的鉴权向量。在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤1012及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤1021及其后续步骤，即再采用“IMS AKA”鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤1021及其后续步骤，即再采用“IMS AKA”鉴权方式进行鉴权。
步骤1012，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1013，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1014，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤1015，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤1016，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。
UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xxAuth_Challenge，因此也无需建立和P-CSCF之间的安全联盟。
图10b所示的步骤1021，S-CSCF在步骤1011中已经保存了从HSS获取的IMS AKA鉴权向量。S-CSCF向I-CSCF发送4xx Auth_Challenge消息，并携带有IMS AKA鉴权信息。
步骤1022，I-CSCF将所述4xx Auth_Challenge消息发送给P-CSCF。
步骤1023，P-CSCF将所述4xx Auth_Challenge消息发送给UE。
步骤1024，UE接收到所述4xx Auth_Challenge消息后，建立和P-CSCF之间的安全联盟，重新向P-CSCF发送新的注册报文Register，并且该Register携带有认证参数。
步骤1025，P-CSCF将UE的注册报文Register发送给I-CSCF。
步骤1026，I-CSCF接收到所述注册报文Register后，与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询用户注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该用户注册报文的S-CSCF。
步骤1027，I-CSCF将注册报文Register转发给步骤1026确定的S-CSCF。
此后，S-CSCF比较以前保存的从HSS获得的认证参数和UE发送过来的认证参数，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤1028，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF。
步骤1029，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1030，如果鉴权成功，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示注册成功，其中2xx表示成功相应的消息，xx为00～99的一个数字。如果鉴权失败，则S-CSCF向I-CSCF发送表示鉴权失败的消息。
步骤1031，I-CSCF将上述消息转发给P-CSCF。
步骤1032，P-CSCF将上述消息转发给UE。
如果是针对第四实施例或第五实施例，可以根据第四实施例或第五实施例与第三实施例的不同之处对本实施例作相应的改动，这里不再赘述。
图11a和11b所示的第八实施例针对的是第一实施例，采用IMS业务层鉴权和接入层鉴权绑定方式失败之后再采用“HTTP DIGEST”鉴权方式进行鉴权。
参考图11a和图11b，本发明的第八实施例包括以下步骤：
步骤1101，UE向P-CSCF发送注册报文Register。
步骤1102，P-CSCF将UE的注册报文Register转发给I-CSCF。
步骤1103，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤1104，I-CSCF将UE的注册报文Register转发给步骤1103中所确定S-CSCF。
步骤1105，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1106，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤1107，HSS检查用户的鉴权签约数据，根据鉴权签约数据得到该用户的鉴权方式默认为IMS业务层鉴权与接入层鉴权绑定，失败之后再采用“HTTP DIGEST”鉴权方式。
步骤1108，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF，即至少包括IMS业务层鉴权和接入层鉴权绑定方式和鉴权参数以及“HTTP DIGEST”鉴权方式和鉴权参数。
步骤1109，S-CSCF保存所有的鉴权方式以及相应的鉴权向量。S-CSCF根据在步骤1108中获得的鉴权方式信息，该用户的鉴权方式默认是业务层鉴权和接入层鉴权绑定，失败后再采用“HTTP DIGEST”。然后向I-CSCF发送4xx Auth_Challenge消息，并在消息的鉴权头域中表明鉴权方式是业务层鉴权和接入层鉴权绑定，即携带鉴权方式指示信息。
步骤1110，I-CSCF将上述4xx Auth_Challenge消息发送给P-CSCF。
步骤1111，P-CSCF接收到“4xx Auth_Challenge”消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将上述4xx Auth_Challenge消息发送给UE，其中不携带Security-Server头。
步骤1112，UE接收到所述4xx Auth_Challenge消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤1113，P-CSCF根据注册报文中的运营商标识以及预先设置的运营商标识与CLF之间的对应关系确定CLF。
步骤1114，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与接入用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤1115，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤1116，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤1117，I-CSCF将包含查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址转发给步骤1116确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤1118，在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤1119及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤1131及其后续步骤，即再采用“HTTP DIGEST”鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤1131及其后续步骤，即再采用“HTTP DIGEST”鉴权方式进行鉴权。
步骤1119，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1120，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1121，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤1122，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤1123，P-CSCF将上述2xx Auth_OK消息发送给UE。
如图11b所示的步骤1131，S-CSCF在步骤1109中已经保存了从HSS获取的HTTP DIGEST鉴权向量。S-CSCF向I-CSCF发送“4xxAuth_Challenge”消息，其中包含HTTP DIGEST鉴权信息参数。
步骤1132，I-CSCF将“4xx Auth_Challenge”消息发送给P-CSCF。
步骤1133，P-CSCF接收到“4xx Auth_Challenge”消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将“4xx Auth_Challenge”消息发送给UE，其中不携带Security-Server头。
步骤1134，UE接收到“4xx Auth_Challenge”消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，并携带用于鉴权的认证参数。
步骤1135，P-CSCF将携带认证参数Register发送给I-CSCF。
步骤1136，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤1137，I-CSCF将注册报文Register转发给步骤1136确定的S-CSCF。
此后，S-CSCF比较以前保存的从HSS获得的认证参数和UE发送过来的认证参数，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤1138，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1139，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1140，S-CSCF向I-CSCF发送表示鉴权成功的200消息，或者表示鉴权失败的消息。在图中仅以鉴权成功时的200消息表示。
步骤1141，I-CSCF将上述消息发送给P-CSCF。
步骤1142，P-CSCF将上述消息发送给UE。
如果是针对第二实施例，可以根据第二实施例与第一实施例的不同之处对本实施例作相应的改动，这里不再赘述。
图12a和12b所示的第九实施例针对的是第一实施例，采用IMS业务层鉴权和接入层鉴权绑定方式失败之后再采用“IMS AKA”鉴权方式进行鉴权。
参考图12a和图12b，本发明的第九实施例包括以下步骤：
步骤1201，UE向P-CSCF发送注册报文Register。
步骤1202，P-CSCF将UE的注册报文Register转发给I-CSCF。
步骤1203，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤1204，I-CSCF将UE的注册报文Register转发给步骤1203中所确定S-CSCF。
步骤1205，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1206，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤1207，HSS检查用户的鉴权签约数据，根据鉴权签约数据得到该用户的鉴权方式默认为IMS业务层鉴权与接入层鉴权绑定，失败之后再采用“IMS AKA”鉴权方式。
步骤1208，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF，即至少包括IMS业务层鉴权和接入层鉴权绑定方式和鉴权参数以及“IMS AKA”鉴权方式和鉴权参数。
步骤1209，S-CSCF保存所有的鉴权方式以及相应的鉴权向量。S-CSCF根据在步骤1208中获得的鉴权方式信息，该用户的鉴权方式默认是业务层鉴权和接入层鉴权绑定，失败后再采用“IMS AKA”。然后向I-CSCF发送4xx Auth_Challenge消息，并在消息的鉴权头域中表明鉴权方式是业务层鉴权和接入层鉴权绑定，即携带鉴权方式指示信息。
步骤1210，I-CSCF将上述4xx Auth_Challenge消息发送给P-CSCF。
步骤1211，P-CSCF接收到“4xx Auth_Challenge”消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将“4xx Auth_Challenge”消息发送给UE，其中不携带Security-Server头。
步骤1212，UE接收到所述4xx Auth_Challenge消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤1213，P-CSCF根据注册报文中的运营商标识以及预先设置的运营商标识与CLF之间的对应关系确定CLF。
步骤1214，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与接入用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤1215，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤1216，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤1217，I-CSCF将包含查询结果的注册报文Register以及P-CSCF所接收的该Register源IP地址转发给步骤1216确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤1218，在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤1219及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤1231及其后续步骤，即再采用“IMS AKA”鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤1231及其后续步骤，即再采用“IMS AKA”鉴权方式进行鉴权。
步骤1219，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1220，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1221，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤1222，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤1223，P-CSCF将上述2xx Auth_OK消息发送给UE。
如图12b所示的步骤1231，S-CSCF在步骤1209中已经保存了从HSS获取的IMS AKA鉴权向量。S-CSCF向I-CSCF发送4xx Auth_Challenge消息，并携带有与IMS AKA鉴权相关的信息。
步骤1232，I-CSCF将所述4xx Auth_Challenge消息发送给P-CSCF。
步骤1233，P-CSCF收到所述4xx Auth_Challenge消息后，建立和UE之间的安全联盟，并将所述4xx Auth_Challenge消息发送给UE。
步骤1234，UE接收到所述4xx Auth_Challenge消息后，建立和P-CSCF之间的安全联盟，重新向P-CSCF发送新的注册报文Register，并且该Register携带有认证参数。
步骤1235，P-CSCF将UE的注册报文Register发送给I-CSCF。
步骤1236，I-CSCF接收到所述注册报文Register后，与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询用户注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该用户注册报文的S-CSCF。
步骤1237，I-CSCF将注册报文Register转发给步骤1236确定的S-CSCF。
此后，S-CSCF比较以前保存的从HSS获得的认证参数和UE发送过来的认证参数，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤1238，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF。
步骤1239，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1240，如果鉴权成功，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示注册成功，其中2xx表示成功相应的消息，xx为00～99的一个数字。如果鉴权失败，则S-CSCF向I-CSCF发送表示鉴权失败的消息。
步骤1241，I-CSCF将上述消息转发给P-CSCF。
步骤1242，P-CSCF将上述消息转发给UE。
如果是针对第二实施例，可以根据第二实施例与第一实施例的不同之处对本实施例作相应的改动，这里不再赘述。
在前面的第六至第九实施例中，IMS业务层和接入层绑定、IMS AKA和HTTP DIGEST等鉴权方式是并列的，本发明的第十实施例和第十一实施例还分别提供了另一种模式，即是否支持IMS业务层和接入层绑定鉴权方式只是HTTP DIGEST或者IMS AKA的子特性而已，而不是地位相等的。在这种模式中，HSS只设置IMS AKA和HTTP DIGEST两种鉴权机制，但可以选择同时设置是否支持IMS业务层和接入层绑定鉴权子特性。
图13a、图13b和13c所示的第十实施例针对的是第六实施例，设置HTTPDIGEST鉴权机制，并可以选择是否支持IMS业务层和接入层绑定鉴权子特性。
参考图13a、图13b和13c，本发明的第十实施例包括以下步骤：
步骤1301，UE向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤1302，P-CSCF根据注册报文中的接入运营商标识以及预先设置的接入运营商标识与CLF之间的对应关系确定CLF。
步骤1303，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤1304，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该注册报文源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤1305，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤1306，I-CSCF将包括上述查询结果的注册报文Register以及P-CSCF所接收的注册报文源IP地址转发给步骤1305确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤1307，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1308，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤1309，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是HTTP DIGEST，并且“是否支持IMS业务层和接入层绑定鉴权”标志为是，表示支持“IMS业务层和接入层绑定鉴权”和HTTP DIGEST相结合的鉴权。
步骤1310，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF，即HTTP DIGEST鉴权方式和鉴权向量以及“是否支持IMS业务层和接入层绑定鉴权”标志为是，同时返回相应的位置信息。
步骤1311，S-CSCF保存鉴权方式以及相应的鉴权向量。在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤1312及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤1321及其后续步骤，即再采用“HTTP DIGEST”鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤1321及其后续步骤，即再采用“HTTP DIGEST”鉴权方式进行鉴权。
步骤1312，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1313，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1314，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤1315，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤1316，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。
UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xxAuth_Challenge，因此也不需要建立和P-CSCF之间的安全联盟。
图13b所示的是“是否支持IMS业务层和接入层绑定鉴权”标志为否的情形，其中步骤1301至步骤1308与图13a中所示的相同，这里不再赘述。其中不同的是步骤1309和步骤1310，如下：
步骤1309 HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是HTTP DIGEST，并且“是否支持IMS业务层和接入层绑定鉴权”标志为否，表示仅支持HTTP DIGEST，而不支持“IMS业务层和接入层绑定鉴权”。
步骤1310，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF，即HTTP DIGEST以及“是否支持IMS业务层和接入层绑定鉴权”标志为否。然后执行步骤13c所示的步骤1321及其后续步骤。
如图13c所示的步骤1321，S-CSCF在步骤1312中已经保存了从HSS获取的HTTP DIGEST鉴权向量。S-CSCF向I-CSCF发送包括HTTP DIGEST鉴权信息的“4xx Auth_Challenge”消息。
步骤1322，I-CSCF将“4xx Auth_Challenge”消息发送给P-CSCF。
步骤1323，P-CSCF接收到“4xx Auth_Challenge”消息后，发现该消息的WWW-Authenticate头中没有完整性密钥IK和加密密钥CK，因此不需要建立和UE之间的安全联盟。P-CSCF将“4xx Auth_Challenge”消息发送给UE，其中不携带Security-Server头。
步骤1324，UE接收到“4xx Auth_Challenge”消息后，没有发现Security-Server头，因此也不需要建立和P-CSCF之间的安全联盟。UE重新向P-CSCF发送注册报文Register，并携带用于鉴权的认证参数。
步骤1325，P-CSCF将携带认证参数Register发送给I-CSCF。
步骤1326，I-CSCF与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询该注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该注册报文的S-CSCF。
步骤1327，I-CSCF将注册报文Register转发给步骤1326确定的S-CSCF。
此后，S-CSCF比较以前保存的从HSS获得的认证参数和UE发送过来的认证参数，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤1328，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1329，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1330，S-CSCF向I-CSCF发送表示鉴权成功的200消息，或者表示鉴权失败的消息。在图中仅以鉴权成功时的200消息表示。
步骤1331，I-CSCF将上述消息发送给P-CSCF。
步骤1332，P-CSCF将上述消息发送给UE。
如果是针对第八实施例，可以根据第八实施例与第六实施例的不同之处对本实施例作相应的改动，这里不再赘述。
图14a、图14b和图14c所示的第十一实施例针对的是第七实施例，设置IMS AKA鉴权机制，并可以选择是否支持IMS业务层和接入层绑定鉴权子特性。
参考图14a、图14b和图14c，本发明的第十一实施例包括以下步骤：
步骤1401，UE向P-CSCF发送注册报文Register，该报文携带有接入运营商标识及接入用户标识。
步骤1402，P-CSCF根据注册报文中的接入运营商标识以及预先设置的接入运营商标识与CLF之间的对应关系确定CLF。
步骤1403，P-CSCF根据注册报文中的接入用户标识，在上面确定的CLF中查询用户在接入层的附着信息。CLF中预先保存了与私有用户标识对应的附着信息的数据记录，所述附着信息包括IP地址信息、位置信息等，但不包括现有技术中的绑定标识。如果CLF中没有该接入用户标识的数据记录，CLF会返回查询失败。
步骤1404，P-CSCF将携带上一步骤中查询结果的注册报文Register以及P-CSCF所接收的该注册报文源IP地址发送给I-CSCF。如果前面的查询成功，则将查询得到的附着信息发送给I-CSCF；如果查询失败，则向I-CSCF上报查询失败信息。
步骤1405，I-CSCF跟HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。
步骤1406，I-CSCF将包括上述查询结果的注册报文Register以及P-CSCF所接收的注册报文源IP地址转发给步骤1405确定的S-CSCF。所述查询结果，在查询成功时为查询得到的附着信息，在查询失败时为上报的查询失败信息。
步骤1407，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1408，S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。
步骤1409，HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS AKA和“是否支持IMS业务层和接入层绑定鉴权”标志为“是”。表示支持“IMS业务层和接入层绑定鉴权”和IMS AKA相结合的鉴权方式。
步骤1410，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF，即IMS AKA鉴权方式和鉴权向量和“是否支持IMS业务层和接入层绑定鉴权”标志为“是”，同时返回相应的位置信息。
步骤1411，S-CSCF保存鉴权方式以及相应的鉴权向量。在查询结果为查询得到的附着信息时，S-CSCF判断P-CSCF收到的注册报文Register的源IP地址与所述从CLF查询得到的附着信息中的IP地址信息是否一致，如果一致，则说明鉴权成功，执行步骤1412及其后续流程，即向UE发送鉴权成功的消息；如果不一致，则说明鉴权失败，执行步骤1421及其后续步骤，即再采用“IMS AKA”鉴权方式进行鉴权。
在查询结果为上报的查询失败信息时，也说明鉴权失败，执行步骤1421及其后续步骤，即再采用“IMS AKA”鉴权方式进行鉴权。
步骤1412，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。
步骤1413，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1414，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示鉴权成功。
步骤1415，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。
步骤1416，P-CSCF接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xx Auth_Challenge，因此不需要建立和UE之间的安全联盟。P-CSCF将上述2xx Auth_OK消息发送给UE。
UE接收到上述2xx Auth_OK消息后，发现以前没有接收到挑战消息4xxAuth_Challenge，因此也无需建立和P-CSCF之间的安全联盟。
图14b所示的是“是否支持IMS业务层和接入层绑定鉴权”标志为否的情形，其中步骤1401至步骤1408与图14a中所示的相同，这里不再赘述。其中不同的是步骤1409和步骤1410，如下：
步骤1409 HSS检查用户的鉴权签约数据，发现该用户的鉴权方式是IMS AKA，并且“是否支持IMS业务层和接入层绑定鉴权”标志为否，表示不支持“IMS业务层和接入层绑定鉴权”。
步骤1410，HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权方式信息发送给S-CSCF，即IMS AKA以及“是否支持IMS业务层和接入层绑定鉴权”标志为否。然后执行步骤14c所示的步骤1421及其后续步骤。
图14c所示的步骤1421，S-CSCF在步骤1412中已经保存了从HSS获取的IMS AKA鉴权向量。S-CSCF向I-CSCF发送4xx Auth_Challenge消息，并携带有IMS AKA鉴权信息。
步骤1422，I-CSCF将所述4xx Auth_Challenge消息发送给P-CSCF。
步骤1423，P-CSCF将所述4xx Auth_Challenge消息发送给UE。
步骤1424，UE接收到所述4xx Auth_Challenge消息后，建立和P-CSCF之间的安全联盟，重新向P-CSCF发送新的注册报文Register，并且该Register携带有认证参数。
步骤1425，P-CSCF将UE的注册报文Register发送给I-CSCF。
步骤1426，I-CSCF接收到所述注册报文Register后，与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询用户注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该用户注册报文的S-CSCF。
步骤1427，I-CSCF将注册报文Register转发给步骤1426确定的S-CSCF。
此后，S-CSCF比较以前保存的从HSS获得的认证参数和UE发送过来的认证参数，当两者一致时，说明鉴权成功，当两者不一致时，说明鉴权失败。
步骤1428，S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF。
步骤1429，S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。
步骤1430，如果鉴权成功，S-CSCF向I-CSCF发送2xx Auth_OK消息，表示注册成功，其中2xx表示成功相应的消息，xx为00～99的一个数字。如果鉴权失败，则S-CSCF向I-CSCF发送表示鉴权失败的消息。
步骤1431，I-CSCF将上述消息转发给P-CSCF。
步骤1432，P-CSCF将上述消息转发给UE。
如果是针对第九实施例，可以根据第九实施例与第七实施例的不同之处对本实施例作相应的改动，这里不再赘述。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (24)
1、一种IP多媒体子系统IMS的鉴权方法，其特征在于，该方法包括以下步骤：
A.代理呼叫会话控制功能实体P-CSCF接收到用户终端UE发送来的注册报文后，根据所述注册报文中的信息以及预先设置的注册报文中的信息与连接位置功能实体CLF的对应关系确定CLF；
B.P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果，并将携带所述查询结果的注册报文发送给询问呼叫会话控制功能实体I-CSCF；
C.I-CSCF将所述注册报文转发给归属用户服务器HSS告知的服务呼叫会话控制功能实体S-CSCF；
D.S-CSCF根据从HSS获取的鉴权方式，对UE进行鉴权得到鉴权结果，并将所述鉴权结果发送给UE。
2、根据权利要求1所述的方法，其特征在于，步骤D中所述鉴权方式为IMS业务层鉴权和接入层鉴权绑定。
3、根据权利要求2所述的方法，其特征在于，步骤A之前进一步包括：
A1.UE向S-CSCF发送注册报文；
A2.S-CSCF向HSS请求所述UE的鉴权向量；
A3.HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定，并向S-CSCF发送包括所述鉴权方式的消息；
A4.S-CSCF向UE发送包括所述鉴权方式的消息；
A5.UE接收到所述包括鉴权方式的消息后，向P-CSCF发送新的注册报文；
步骤A、步骤B及步骤C中所述的注册报文为所述新的注册报文。
4、根据权利要求2所述的方法，其特征在于，步骤D之前进一步包括：
S-CSCF向HSS请求所述UE的鉴权向量；
HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方式是IMS业务层鉴权和业务层绑定，并向S-CSCF发送包括所述鉴权方式的消息。
5、根据权利要求2所述的方法，其特征在于，步骤A中所述注册报文中的信息为接入运营商标识或所述注册报文源IP地址。
6、根据权利要求2所述的方法，其特征在于，所述注册报文包括接入用户标识；预先在CLF中保存了与所述接入用户标识对应的UE在接入网中的附着信息；
步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：
P-CSCF根据所述接入用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述接入用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
7、根据权利要求2所述的方法，其特征在于，所述注册报文包括私有用户标识；预先在CLF中保存了与所述私有用户标识对应的UE在接入网中的附着信息；
步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：
P-CSCF根据所述私有用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述私有用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
8、根据权利要求2、6或7所述的方法，其特征在于，
步骤B进一步包括P-CSCF将所收到的注册报文的源IP地址发送给I-CSCF的步骤；
步骤C进一步包括I-CSCF将所述注册报文源IP地址转发给所述S-CSCF的步骤；
步骤D中所述对UE进行鉴权得到鉴权结果的步骤包括：
在所述查询结果包括IP地址信息时，S-CSCF比较所述P-CSCF所收到的注册报文源IP源地址与所述查询结果中的IP地址信息，如果一致，则得到鉴权成功的鉴权结果，否则得到鉴权失败的鉴权结果；在所述查询结果为查询失败信息时，S-CSCF得到鉴权失败的鉴权结果。
9、根据权利要求2所述的方法，其特征在于，预先在CLF中保存了与注册报文源IP地址对应的UE在接入网中的附着信息；
步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：
P-CSCF根据所述注册报文源IP地址向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述注册报文源IP地址对应的接入用户关联信息的附着信息时，CLF向P-CSCF返回包括所述接入用户关联信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
10、根据权利要求2或9所述的方法，其特征在于，
步骤D中所述对UE进行鉴权得到鉴权结果之前进一步包括S-CSCF从HSS获得预先保存在HSS的绑定的接入用户关联信息的步骤；
步骤D中所述对UE进行鉴权得到鉴权结果的步骤包括：
在所述查询结果包括接入用户关联信息时，S-CSCF比较所述从HSS获得的绑定的接入用户关联信息与所述查询结果中的接入用户关联信息，如果一致，则得到鉴权成功的鉴权结果，否则得到鉴权失败的鉴权结果；在所述查询结果为查询失败信息时，S-CSCF得到鉴权失败的鉴权结果。
11、根据权利要求10所述的方法，其特征在于，所述接入用户关联信息为接入用户标识、位置信息或IP地址信息。
12、根据权利要求1所述的方法，其特征在于，步骤D中所述鉴权方式为：先采用IMS业务层鉴权和接入层鉴权绑定的鉴权方式，在IMS业务层鉴权和接入层鉴权绑定的鉴权方式进行鉴权失败之后再采用第二鉴权方式；
步骤D包括：S-CSCF保存从HSS获取的IMS业务层鉴权和接入层鉴权绑定的鉴权方式以及相应的鉴权参数，以及第二种鉴权方式以及相应的鉴权参数，S-CSCF首先采用IMS业务层鉴权和接入层鉴权绑定的方式，对UE进行鉴权得到鉴权结果，在鉴权结果为成功时，将该鉴权结果发送给UE；在鉴权结果为失败时，再采用第二鉴权方式对UE进行鉴权得到鉴权结果，并将该鉴权结果发送给UE。
13、根据权利要求12所述的方法，其特征在于，所述第二鉴权方式为超文本传输协议摘要HTTP DIGEST方式。
14、根据权利要求13所述的方法，其特征在于，步骤D中所述采用HTTP DIGEST鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：
D11.S-CSCF向UE发送包括所述HTTP DIGEST鉴权方式的挑战消息；
D12.UE接收到所述包括HTTP DIGEST鉴权方式的挑战消息后，向S-CSCF发送包含认证参数的注册消息；
D13.S-CSCF执行HTTP DIGEST的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
15、根据权利要求12所述的方法，其特征在于，所述第二鉴权方式为IMS AKA方式。
16、根据权利要求15所述的方法，其特征在于，步骤D中所述采用IMSAKA鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：
D21.S-CSCF向UE发送包括所述IMS AKA鉴权方式的挑战消息；
D22.UE接收到所述包括IMS AKA鉴权方式的挑战消息后，向S-CSCF发送包括认证参数的注册消息；
D23.S-CSCF执行IMS AKA的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
17、根据权利要求14或16所述的方法，其特征在于，
步骤A中所述注册报文中的信息为接入运营商标识；
所述注册报文包括接入用户标识；预先在CLF中保存了与所述接入用户标识对应的UE在接入网中的附着信息；
步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述接入用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述接入用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
18、根据权利要求14或16所述的方法，其特征在于，步骤A之前进一步包括：
A1.UE向S-CSCF发送注册报文；
A2.S-CSCF向HSS请求所述UE的鉴权向量；
A3.HSS根据预先设置的用户鉴权签约数据发现该用户的鉴权方式是先采用IMS业务层鉴权和接入层鉴权绑定的鉴权方式，在IMS业务层鉴权和接入层鉴权绑定的鉴权方式进行鉴权失败之后再采用第二鉴权方式；
A4.S-CSCF向UE发送包括所述鉴权方式的消息；
A5.UE接收到所述包括鉴权方式的消息后，向P-CSCF发送新的注册报文；
步骤A、步骤B及步骤C中所述的注册报文为所述新的注册报文。
19、根据权利要求1所述的方法，其特征在于，步骤D中所述鉴权方式为：HSS在设置第二鉴权方式时，同时嵌套设置“是否支持IMS业务层和接入层绑定鉴权”标志；
步骤D包括：S-CSCF收到HSS发送来的第二鉴权方式，以及同时包括“是否支持IMS业务层和接入层绑定鉴权”标志的鉴权方式；当所述标志表示支持IMS业务层鉴权和接入层鉴权绑定的鉴权方式时，S-CSCF首先保存从HSS获取的第二鉴权方式以及相应的鉴权参数，然后采用IMS业务层鉴权和接入层鉴权绑定的方式，对UE进行鉴权得到鉴权结果，在鉴权结果为成功时，将该鉴权结果发送给UE；在鉴权结果为失败时，再采用第二鉴权方式对UE进行鉴权得到鉴权结果，并将该鉴权结果发送给UE；当所述标志表示不支持IMS业务层鉴权和接入层鉴权绑定的鉴权方式时，S-CSCF直接采用第二鉴权方式对UE进行鉴权得到鉴权结果，并将该鉴权结果发送给UE。
20、根据权利要求19所述的方法，其特征在于，所述第二鉴权方式为HTTP DIGEST方式。
21、根据权利要求20所述的方法，其特征在于，步骤D中所述采用HTTP DIGEST鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：
D11.S-CSCF向UE发送包括所述HTTP DIGEST鉴权方式的挑战消息；
D12.UE接收到所述包括HTTP DIGEST鉴权方式的挑战消息后，向S-CSCF发送包含认证参数的注册消息；
D13.S-CSCF执行HTTP DIGEST的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
22、根据权利要求19所述的方法，其特征在于，所述第二鉴权方式为IMS AKA方式。
23、根据权利要求22所述的方法，其特征在于，步骤D中所述采用IMSAKA鉴权方式对UE进行鉴权得到鉴权结果并将该鉴权结果发送给UE的步骤包括：
D21.S-CSCF向UE发送包括所述IMS AKA鉴权方式的挑战消息；
D22.UE接收到所述包括IMS AKA鉴权方式的挑战消息后，向S-CSCF发送包括认证参数的注册消息；
D23.S-CSCF执行IMS AKA的鉴权过程，当鉴权成功时，向UE发送表示鉴权成功的消息；当鉴权失败时，向UE发送表示鉴权失败的消息。
24、根据权利要求21或23所述的方法，其特征在于，步骤A中所述注册报文中的信息为接入运营商标识；
所述注册报文包括接入用户标识；预先在CLF中保存了与所述接入用户标识对应的UE在接入网中的附着信息；
步骤B中所述P-CSCF向所述CLF查询UE在接入网中的附着信息得到查询结果的步骤包括：P-CSCF根据所述接入用户标识向所述CLF查询UE在接入网中的附着信息；在CLF中存在与所述接入用户标识对应的IP地址信息的附着信息时，CLF向P-CSCF返回包括所述IP地址信息的查询结果，否则向P-CSCF返回查询失败的查询结果。
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB200510109162XA CN100395976C (zh) | 2005-07-05 | 2005-10-18 | 一种因特网协议多媒体子系统的鉴权方法 |
| CN200680010294.XA CN101151869B (zh) | 2005-07-05 | 2006-07-05 | 因特网协议多媒体子系统的鉴权方法 |
| EP06753103A EP1853032B1 (en) | 2005-07-05 | 2006-07-05 | An authentication method for the ip multimedia subsystem |
| AT06753103T ATE453282T1 (de) | 2005-07-05 | 2006-07-05 | Authentifizierungsverfahren für das ip multimedia subsystem |
| PCT/CN2006/001569 WO2007003140A1 (fr) | 2005-07-05 | 2006-07-05 | Procede d'authentification de sous-systeme multimedia sous protocole ip |
| DE602006011282T DE602006011282D1 (de) | 2005-07-05 | 2006-07-05 | Authentifizierungsverfahren für das ip multimedia subsystem |
| BRPI0612687-1A BRPI0612687B1 (pt) | 2005-07-05 | 2006-07-05 | Método de autenticação em subsistema multimídia ip |
| US11/842,668 US7974604B2 (en) | 2005-07-05 | 2007-08-21 | Method of authentication in IP multimedia subsystem |
| US13/092,413 US8364121B2 (en) | 2005-07-05 | 2011-04-22 | Method of authentication in IP multimedia subsystem |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200510082907.8 | 2005-07-05 | ||
| CN200510082907 | 2005-07-05 | ||
| CN200510093216.8 | 2005-08-19 | ||
| CNB200510109162XA CN100395976C (zh) | 2005-07-05 | 2005-10-18 | 一种因特网协议多媒体子系统的鉴权方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1893352A true CN1893352A (zh) | 2007-01-10 |
| CN100395976C CN100395976C (zh) | 2008-06-18 |
Family
ID=37597889
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB200510109162XA Active CN100395976C (zh) | 2005-07-05 | 2005-10-18 | 一种因特网协议多媒体子系统的鉴权方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100395976C (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008089699A1 (fr) * | 2007-01-23 | 2008-07-31 | Huawei Technologies Co., Ltd. | Procédé et système d'authentification d'un terminal utilisateur dans un réseau ims |
| WO2010069197A1 (zh) * | 2008-12-17 | 2010-06-24 | 华为技术有限公司 | 多媒体子系统业务处理的方法、装置和多媒体子系统 |
| CN101959172A (zh) * | 2009-07-17 | 2011-01-26 | 中兴通讯股份有限公司 | Ngn中身份标识和位置分离的附着方法及系统 |
| CN101577910B (zh) * | 2008-07-29 | 2011-03-16 | 中兴通讯股份有限公司 | 一种ip多媒体子系统中的注册鉴权方法 |
| CN102984164A (zh) * | 2012-12-06 | 2013-03-20 | 大唐移动通信设备有限公司 | 一种ims注册方法及装置 |
| WO2014114088A1 (zh) * | 2013-01-25 | 2014-07-31 | 中兴通讯股份有限公司 | 一种ngn下实现宽带业务功能的方法及业务平台 |
| CN104066109A (zh) * | 2014-06-30 | 2014-09-24 | 中国联合网络通信集团有限公司 | Ims网络的注册管理方法、装置及系统 |
| CN105450621A (zh) * | 2014-09-30 | 2016-03-30 | 中兴通讯股份有限公司 | 终呼处理方法、装置及系统 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1853032B1 (en) | 2005-07-05 | 2009-12-23 | Huawei Technologies Co., Ltd. | An authentication method for the ip multimedia subsystem |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10223248A1 (de) * | 2002-05-22 | 2003-12-04 | Siemens Ag | Verfahren zum Registrieren eines Kommunikationsendgeräts |
| US20040184432A1 (en) * | 2003-03-19 | 2004-09-23 | Ralitsa Gateva | Method for controlling streaming services |
| US20050060411A1 (en) * | 2003-09-16 | 2005-03-17 | Stephane Coulombe | System and method for adaptation of peer-to-peer multimedia sessions |
-
2005
- 2005-10-18 CN CNB200510109162XA patent/CN100395976C/zh active Active
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008089699A1 (fr) * | 2007-01-23 | 2008-07-31 | Huawei Technologies Co., Ltd. | Procédé et système d'authentification d'un terminal utilisateur dans un réseau ims |
| CN101577910B (zh) * | 2008-07-29 | 2011-03-16 | 中兴通讯股份有限公司 | 一种ip多媒体子系统中的注册鉴权方法 |
| WO2010069197A1 (zh) * | 2008-12-17 | 2010-06-24 | 华为技术有限公司 | 多媒体子系统业务处理的方法、装置和多媒体子系统 |
| CN101959172A (zh) * | 2009-07-17 | 2011-01-26 | 中兴通讯股份有限公司 | Ngn中身份标识和位置分离的附着方法及系统 |
| CN102984164A (zh) * | 2012-12-06 | 2013-03-20 | 大唐移动通信设备有限公司 | 一种ims注册方法及装置 |
| CN102984164B (zh) * | 2012-12-06 | 2015-06-17 | 大唐移动通信设备有限公司 | 一种ims注册方法及装置 |
| WO2014114088A1 (zh) * | 2013-01-25 | 2014-07-31 | 中兴通讯股份有限公司 | 一种ngn下实现宽带业务功能的方法及业务平台 |
| CN104066109A (zh) * | 2014-06-30 | 2014-09-24 | 中国联合网络通信集团有限公司 | Ims网络的注册管理方法、装置及系统 |
| CN105450621A (zh) * | 2014-09-30 | 2016-03-30 | 中兴通讯股份有限公司 | 终呼处理方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100395976C (zh) | 2008-06-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1893352A (zh) | 一种因特网协议多媒体子系统的鉴权方法 | |
| CN1819671A (zh) | 关于按键通话发言权和队列信息的方法及其相关装置 | |
| CN1794705A (zh) | 即时消息用户使用其它即时消息系统聊天室的方法及系统 | |
| CN1655553A (zh) | 便于第三方呼叫和设备控制的系统和方法 | |
| CN1269337C (zh) | 内容自适应服务控制方法 | |
| CN101043744A (zh) | 一种ims网络中用户终端接入鉴权的方法 | |
| CN1801814A (zh) | 一种离线消息发送和接收方法 | |
| CN1881958A (zh) | 一种用户设备从分组域向电路域切换的方法及装置 | |
| CN1770805A (zh) | 计算机辅助管理电话会议的方法以及电话会议服务器装置 | |
| CN1147176C (zh) | 呼叫控制和载体控制分离的无线网及其中建立呼叫的方法 | |
| CN1656482A (zh) | 在使用用户档案web门户的电信网中用于服务和应用个性化的方法和装置 | |
| CN101053224A (zh) | 通信系统、信息处理设备、中介服务器、标识信息传送服务器及其通信方法和程序 | |
| CN1969292A (zh) | 用户轮廓管理系统 | |
| CN1832457A (zh) | 数据包通信装置及功能扩展方法 | |
| CN1801970A (zh) | 自动产生和/或控制有多个参加者的电信会议的方法及设备 | |
| CN1846375A (zh) | 道路车间通信系统 | |
| CN1889742A (zh) | 基于设备管理的数据共享方法及其数据备份恢复方法 | |
| CN1405986A (zh) | 第2层虚拟专用网络中继系统 | |
| CN1882119A (zh) | 一种实现电路域和分组域互切换的装置、系统和方法 | |
| CN1490733A (zh) | 服务提供方法 | |
| CN101030138A (zh) | 应用构架 | |
| CN1930838A (zh) | 信息处理装置、服务器、通信系统、地址决定方法、地址变更方法及程序 | |
| CN1507202A (zh) | 设备管理系统、设备管理终端、网络设备、终端程序、设备程序以及设备管理方法 | |
| CN1706126A (zh) | 移动通信网络的测位系统和测位方法 | |
| CN1852267A (zh) | 一种不同类型存在系统间的互连方法及互连服务器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |