Layer7 Access Management

Expand all | Collapse all

How to enable two trusted identity providers for Sharepoint-CA SSO Integration

  • 1.  How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-02-2018 10:35 AM

    Implementing SharePoint 2010 and CA SSO Integration. There are two different user directories(usertype1 and usertype2), sharepoint created two separate Trusted Identity Providers(TIP) for each user directory. Can't use common TIP because user directories have unique user identifier. Now if we make TIP of usertype1 as default in sharepoint, we're unable to authenticate usertype2.  Right now, we have disabled the default TIP in sharepoint, so now Sharepoint throws a credential selector login prompt where you have to choose the appropriate TIP for the corresponding usertype. Able to authenticate both usertype1 and usertype2. But this is just a work around, how do we make it work with two TIPs by selecting one of it as Default ? 



  • 2.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-02-2018 11:06 AM

    OPTION - 1 : USING A SINGLE TIP

     

    Could we not combine Attribute Mapping and support for multiple user directories in CA SharePoint Agent to achieve this. Using Attribute Mapping we hide the underlying different schematics. Thus even though the different User Directories have different Unique Identifier, we create an Alias which is common but maps to different unique identifier in each UD. Thus you could use a single TIP (Trusted Identity Token Issuer) with the Alias (Attribute Mapping) without having to worry about different schematics.

     

    https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/policy-server-configuration/user-directories/user-attribute-mapping#UserAttributeMapping-HowAttributeMappingWorks

     

    https://docops.ca.com/ca-single-sign-on-agent-for-sharepoint/12-52-sp1/en/release-notes/new-features#NewFeatures-MultipleUserDirectoryConnectionsSupported

     

    https://docops.ca.com/ca-single-sign-on-agent-for-sharepoint/12-52-sp1/en/configuring/configure-multiple-user-directories

     

    https://docops.ca.com/ca-single-sign-on-agent-for-sharepoint/12-52-sp1/en/configuring/disable-client-loopback-after-configuring-multiple-user-directories

     

     

     

     

    OPTION - 2 : USING MULTIPLE TIPS FOR THE SAME WEB CONTENT

     

    This was a design put together a long while ago even before we started support multiple user directories in CA SharePoint Agent. It is pretty self explanatory if you see the design.

     



  • 3.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-02-2018 05:28 PM

    Thanks for the response but when we use single TIP, we create useridentifier and map different unique identifier (uid1 and uid2) according to respective user directory,it is failing because the userdirectory2 is trying to look up for attribute uid1 which is not defined in userdirectory2.



  • 4.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-02-2018 06:25 PM

    Is it possible to add a screenshot of what is being configured, especially

    • Both User Directory Object Attribute Mapping.
    • SPConnectionWizard Screen which displays the Attributes to be passed as responses within the WSFED Token.
    • SharePoint PeoplePicker Screenshot.
    • TIP Creation "powershell" script.


  • 5.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-03-2018 04:58 PM

    I would open a ticket with CA Support and upload the screenshots you have requested. Would there be a way you can look that up internally ?



  • 6.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-03-2018 05:04 PM

    Yes paste the case number here OR email it to me using a Private Message on Communities. Once we raise a case a Support Engg would look into it dedicatedly. Reference the communities link in the case. That way there is two way update of what has transpired till now. I’ll just chime in on the case if I see an anomaly.



  • 7.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-03-2018 06:14 PM

    Here is the CASE NUMBER 00927610. Since we did changes during testing i will update the current TIP Creation "powershell" script tomorrow to the case notes. 



  • 8.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-04-2018 02:27 PM

    Updated the ps1 powershell script to the case 



  • 9.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-04-2018 03:26 PM

    Updated case note based on the screenshot. Let know if it helps!



  • 10.  Re: How to enable two trusted identity providers for Sharepoint-CA SSO Integration

    Posted 01-08-2018 05:01 PM

    Avinash ag0759

     

    I received a very good and detailed feedback from the support team (Thank You Support!). It helped me understand the legacy (history), sequence of architected solution and the solution architecture itself. I agree with Support's detailing and inference.

     

     Here's a simple reverse engineering, Two Authentication Schemes (unique to each UserStore i.e. one Custom AuthScheme for DB2 and other for AD). This means Two Authentication URLs, which means Two Federation Objects (Legacy or Partnership). Two Legacy Federation Objects means, Two SharePoint Connections, thus two powershells scripts i.e. two TIPs. Hence even if we make the IdentifierClaim the same, underlying they are two different TIPs. Thus what has been architectured currently is correct.

     

    As I mentioned if we want to move away i.e. Getting you to a single TIP, with Single IdentifierClaim, will need to revamp the entire solution. This will impact not only the SharePoint WebSites, but also beyond that e.g. unifying into a single authentication scheme, which means you'd need to cascade the custom authentication functions to another component. 

     

    Alternatively you could check with Microsoft Support for inputs as recommended in the case.