INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service-...

19
INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service-oriented abstraction layer for Identity and Access Management Integration with other IDM services was acknowledged, expected, and designed for!

Transcript of INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service-...

Page 1: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

INTEGRATION WITH OTHER IDM SOLUTIONS

• Remember…

• The primary goal of KIM was to build a service-oriented abstraction layer for Identity and Access Management

• Integration with other IDM services was acknowledged, expected, and designed for!

Page 2: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION

Integration with various Identity Management Components

Page 3: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION

Rice Database

Identity Service

Responsibility Service

Permission Service

Group Service

Role Service

KIM Service Layer

Reference Implementations

Page 4: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION WITH

• CAS – Authentication system for Single Sign On (SSO)

• Two ways to integrate:

• CAS Server

• Rice Client Application

• Integration with Rice Client application will be the most likely integration scenario

• this is what we will focus on

Page 5: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

CAS – RICE CLIENT INTEGRATION

• Integrate the CAS client with:

• Kuali Rice Standalone Server

• A Kuali Rice client application

• KIM provides an “AuthenticationService” which is used to inform the Rice framework about the authenticated principal

• Default implementation simply reads REMOTE_USER

• Sufficient for CAS integration

Page 6: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

CAS – SETUP

• Simply configure the standard CAS servlet filters in your web.xml as you would normally

• AuthenticationFilter

• Cas20ProxyReceivingTicketValidationFilter

• HttpServletRequestWrapperFilter

• The usernames entered into the CAS login must match the principal names in your KIM implementation

Page 7: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION WITH

• Microsoft Active Directory provides “LDAP-like” directory services among other network services

• You can integrate with this through LDAP (see next topic)

• Can also use this for groups

• This particular usage has been implemented at Indiana University

• We will look at it in detail during the case studies

Page 8: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

INTEGRATING KIM WITH LDAP FOR IDENTITY

• LDAP Integration Efforts

• University of Arizona

• San Joaquin Delta College

• UC Davis

• Naval Post Graduate School

• Others…

• rSmart has worked with these various institutions to implement this integration

Page 9: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

INTEGRATING KIM WITH LDAP FOR IDENTITY

• Will be included as a standard feature in a future version of Kuali Rice.

• Code exists in Rice 2.0, not fully tested for Beta1

• Essentially involves customizing the IdentityService to load entity data from LDAP

• Will learn more details about how this works in the University of Arizona case study

Page 10: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION WITH

• Intra-campus Web SSO

• Federated Access to a Rice application

• Using Shibboleth Attributes for KIM authorization

Page 11: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

FEDERATED AUTHENTICATION

Shibboleth Login Process

Page 12: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

FEDERATED AUTHENTICATION

• Protecting a Rice application as a Service Provider (SP)

• A web server and openssl must be available first

• Add Shibboleth filters to the web server.

• Metadata defines the attributes to be passed between the Identity Provider and Service Provider.

• Override KIM Authentication Service

Page 13: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

FEDERATED AUTHENTICATIONMetadata Example:

<AttributeRule

Name=“urn:mace:dir:attribute-def:eduPersonPrincipalName”

Header=“REMOTE_USER”

Alias=“eppn”>

<AnySite>

<AnyValue/>

</AnySite>

</AttributeRule>

Page 14: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

AUTHORIZATION ATTRIBUTES

• Using Shibboleth Attributes for KIM Authorization

• Entity Attributes

• Group

• Roles

• Permissions / Responsibilities

Page 15: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION WITH

• In collaboration with Kuali Rice, the Internet2 Grouper team created a connector from the KIM GroupService to Grouper

• This connector was released and is available in Grouper 1.6 and later releases

Page 16: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

ADAPTER OVERVIEW

• Custom Implementation of KIM Services using Grouper Client API

• GroupService

• GroupUpdateService

• IdentityService

Page 17: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

INSTALLATION

• grouperClient.jar

• grouperKimConnector.jar

• grouper.client.properties

• Override kimGroupService and kimIdentityService

Page 18: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

HOW TO OVERRIDE A KIM SERVICE

<beans xmlns=http://www.springframework.org/schema/beans

<bean id="kimGroupService" class="edu.internet2.middleware.grouperKimConnector.group.GrouperKimGroupServiceImpl"/>

</beans>

Page 19: INTEGRATION WITH OTHER IDM SOLUTIONS Remember… The primary goal of KIM was to build a service- oriented abstraction layer for Identity and Access Management.

KIM INTEGRATION WITH• Recall…

• Earlier we stated that KIM is NOT an identity aggregator or provisioning tool

• However, Microsoft Forefront has this functionality

• Indiana University has used this tool as part of it’s Kuali Identity Management implementation

• Essentially synchronizes identities from multiple sources into our KIM database

• Will talk about this more in the IU case study