统的令牌，用户可以通过该令牌通过第一认证系统的认证，并通过该令牌对应的第二认证系统的令牌通过第二认证系统的认证，即可以在系统集成时，完成公同认证。
【附图说明】
[0052]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
[0053]图1为本发明实施例所提供的系统集成的认证方法的流程图；
[0054]图2为本发明实施例所提供的Openstack系统集成的认证方法的流程示意图；
[0055]图3为本发明实施例所提供的Openstack系统集成的访问资源的方法的流程示意图；
[0056]图4为本发明实施例所提供的系统集成的认证系统的结构框图；
[0057]图5为本发明实施例所提供的另一系统集成的认证系统的结构框图。
【具体实施方式】
[0058]本发明的核心是提供一种系统集成的认证方法，该方法能够在系统集成时，完成公同认证;本发明的另一目的是提供一种系统集成的认证系统。
[0059]为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0060]请参考图1，图1为本发明实施例所提供的系统集成的认证方法的流程图；该方法可以包括:
[0061 ] slOO、接收用户发送的认证信息；
[0062]SllO、判断所述认证信息中是否含有令牌；
[0063]sl20、若未含有，则根据所述认证信息，利用第一认证系统进行用户身份认证，若用户身份认证通过，则生成第一令牌及对应的第二令牌，并返回用户所述第一令牌，完成认证；
[0064]其中，未含有的话，这里需要首先进行用户的身份验证，当身份验证通过后，生成两个认证系统的对应的两个令牌，完成认证。其中优选的，所述根据所述认证信息，利用第一认证系统进行用户身份认证，若用户身份认证通过，则生成第一令牌及对应的第二令牌可以包括:
[0065]根据所述认证信息，利用第一认证系统进行用户身份认证；
[0066]若用户身份认证通过，则在所述第一认证系统获取用户身份对应的所述第二认证系统的用户信息；
[0067]利用所述第二认证系统的用户信息获取对应的第二令牌，并将所述第二令牌返回给所述第一认证系统；
[0068]所述第一认证系统根据接收到的所述第二令牌，生成对应的第一令牌，将所述第一令牌和所述第二令牌映射保存。
[0069]sl30、若含有，则利用所述第一认证系统认证所述令牌是否是第一令牌，
[0070]sl40、若是第一令牌，则生成与所述第一令牌对应的第二令牌，完成认证；
[0071]sl50、若不是第一令牌，则利用第二认证系统认证所述令牌是否是第二令牌，若是第二令牌，则生成与所述第二令牌对应的第一令牌，并返回用户生成的所述第一令牌，完成认证。
[0072]其中，在含有令牌时，通过判断该令牌是哪个认证系统的令牌，在生成该令牌的对应的另一个认证系统的令牌，完成两个认证系统的对应的两个令牌，完成认证。
[0073]其中，上述过程可以用于具有两种不同的认证系统的系统进行集成时，可以进行混合认证，也即利用原有的认证系统的认证方式进行统一的认证，这样可以满足不同认证模型的需求，又可以把系统集成的成本降到最低。该方法主要是进行两个认证系统的用户信息映射，进而进行令牌映射，通过对令牌的映射管理，实现快速对用户进行认证。
[0074]其中优选的，所述第一认证系统获取所述第二认证系统的用户信息之前，可以包括:
[0075]利用所述第一认证系统将所述第二认证系统的用户信息和所有的用户信息进行链接；
[0076]所述第一认证系统通过所述第二认证系统开放的接口，获取所述第二认证系统的用户信息，并保存到所述第一认证系统的用户信息库中；
[0077]通过所述第一认证系统的策略机制，映射其他系统的用户信息到所述第二认证系统的用户信息。
[0078]其中，通过上述步骤完成两个认证系统的用户信息的映射对应。
[0079]优选的，所述将所述第一令牌和所述第二令牌映射保存可以包括:
[0080]将所述第一令牌和所述第二令牌存放到sess1n对象中；
[0081 ] 将所述sess1n对象进行hash缓存。
[0082]基于上述具体实施例，下面举例子说明上述的具体实现过程:
[0083]例如解决其他系统和Openstack进行集成时的统一认证问题，即第一认证系统为OpenAM，第二认证系统为Keystone混合认证的方法；
[0084]首先，建立认证模型:
[0085]keystone是针对Openstack设计的认证机制，具有一定的应用场景的局限性，其他应用系统就会选择别的认证中心ο这里使用OpenAM，OpenAM是一款灵活性很高的认证、授权系统。如果其他系统的用户需要访问keystone保护的资源，则需要获取keystone的认证信息。这时，就需要OpenAM把key s tone的用户信息和所有的用户信息进行一个链接。OpenAM通过keystone开放的接口，获取keystone相应的用户信息，保存到自己的用户信息库中。然后通过OpenAM的策略机制，映射其他系统的用户到key stone的用户信息。这里的策略机制，需要根据不同的应用系统设计不同的规则。即用户通过OpenAM的认证后，可以申请获取keystone的用户信息，从而达到其他系统可以访问keystone保护的资源的目的。这样就建立了 OpenAM和Keystone共同认证的模型，OpenAM在Keystone的前面进行认证。
[0086]其次，建立令牌即token管理:
[0087]token在认证系统中广泛的使用，OpenAM和keystone中也都使用token机制进行认证。用户想要通过OpenAM管理的统一认证中心访问keystone保护的Openstack中的资源，就需要对token进行特殊的处理。通过OpenAM认证的请求，OpenAM会把OpenAM用户转换成Key s tone用户信息，持有Key s tone用户信息去key stone系统获取相应的token，存放到OpenAM中的库中。然后与此同时生成另外一个OpenAM的token，和keystone生成的token，形成--对应的关系。为了加速认证的反应速度，在OpenAM的节点，使用缓存技术，把token_
openam和token_keystone放到一个sess1n对象中，这样就保证--对应，把sess1n对象放到缓存中，使用OpenAM的用户信息进行hash缓存，加速认证过程。
[0088]通过上述准备，具体进行认证的过程如下:
[0089]用户user发送用户信息到第一认证系统即OpenAM所在节点，进行认证，OpenAM会首先根据请求，查看是否包含有token，如果没有则是用户信息认证。根据用户信息在OpenAM中认证，如果通过认证则从OpenAM库中获取key stone用户信息，然后使用key stone用户信息去keystone中获取token。如果能够成功返回keystone的token即返回第二认证系统的第二令牌，则同时也生成一个OpenAM的token即第一认证系统的第一令牌，然后保存到一个sess1n中，进行hash缓存；然