locked
Sharepoint Claims based authentication and Single Sign on RRS feed

  • Question

  • Hi Gurus

    I wanted to ask you a few questions about a solution I am working on at the moment. I shall appreciate any assistance in this regard. 

    A brief synopsis of the solution:

    The customer has a working ADFS solution in place. They have a SharePoint site where users will come, click on a URL and get redirected to a partner portal, where they will be logged in without being prompted for their credentials. At the moment the customer has no way of identifying users in the SharePoint site. We are working closely with the partner to integrate their portal in the customer environment. Their portal is Single Sign on and Security Assertion Markup Language (SAML) aware. Insight will also be delivering a FIM infrastructure with the Synchronization and Password Reset Portal services enabled. The plan is to have the FIM sync the account details from the customer’s AD, and submit it to the partner portal’s web service. The Partner will not be providing access to their LDAP directory to CUSTOMER. Rather they will be providing a web service (a Clearview web server) for FIM server to send the AD account info to. The partner will manage the data from their end to keep their LDAP directory in sync with the customer AD. The single sign on solution of the partner works on the assumption that the users need to be authenticated when they click on the URL so that their session information can be passed to the partner portal. 

    The questions I have are as follows: 

    SharePoint questions

    • To authenticate external/internal users to the Sharepoint site, should claims based authentication be used in SharePoint? Do you believe that there are any other options than Claims based authentication?
      • Can SharePoint leverage the existing ADFS implementation or will the claims based authentication mandate users to login again using their credentials when they arrive at the SharePoint site?
    • If we wanted to notify the users Can the users be reminded/notified about the impending expiry of their password? Can that be done natively through SharePoint or this needs to be done at the AD level? That is, to inform the users of password expiry, can there be a SharePoint page or can they be informed by AD?

                    FIM questions -

    • If the notification can be configured, then in the notification, can the URL for the Password Reset Portal be included? That is, if it is a SharePoint page then it needs to display the URL of the password portal. The same for the email notification.
      • Alternatively if the password has already expired can the users be redirected to the portal instead of telling them that the password has expired?
    • Will we be able to manually trigger sending a password reset link to an email address not tied to the user’s AD account? This is for first time external users who will not have an email account in the customer’s environment.
    • Considering the situation where FIM Synchronization service is sending the account information to a web service, the question is can FIM Directory Sync do that out of the box? Partner has indicated that no customization will be needed on the FIM, but I wanted to confirm.
      • For the FIM server to work with the web service, does it need to communicate over a VPN tunnel or just normal HTTPS traffic over port 443 can work as well? What is the supported and suggested method to do this? 

    Please let me know what you think. Thanks in advance

    Thursday, November 21, 2013 6:04 AM

Answers

  • By way forward, I mean that "Classic" (non-claims) is deprecated. It is still possible to use in SharePoint 2013, but requires PowerShell to set up the Web App with Classic auth.

    So for the User Profile web service, you'll want to look at leveraging the SharePoint Connector for FIM and set up the UPA to use an External Identity Manager.  Search for External on my site and you should find the details.  Note that I believe the Connector is not RTW yet, and you will want to contact the program owners (their email is listed on the Connect site) about using it in production. If you're not referring to the UPA, then the web service would have to be able to consume what you're sending, which may require custom development of a management agent.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, November 21, 2013 6:01 PM

All replies

  • 1) You must use Claims to use SAML (or FBA).  It is also the "way forward".  SharePoint can leverage an existing ADFS implementation.  Typically the route they take is SharePoint (please auth) -> ADFS (auth) -> (redirect) SharePoint.

    2) Probably should be done in AD, this isn't something that is going to be passed in a claim.  You could create a webpart that looks directly at the user's AD account and provides the information, though.

    3) Again, would require a custom webpart or 3rd party webpart.

    4) Not really SharePoint-specific, you would have to have logic, likely in FIM, to do this, but I haven't used the FIM SSPR.

    5) Which Web Service are you talking about here?


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, November 21, 2013 6:12 AM
  • Hi Trevor 

    Thank you so much for the prompt responses to my question. If I may I want to ask some questions based on your answers. Please pardon my ignorance.

    1) You must use Claims to use SAML (or FBA).  It is also the "way forward".  SharePoint can leverage an existing ADFS implementation.  Typically the route they take is SharePoint (please auth) -> ADFS (auth) -> (redirect) SharePoint. - As part of the authentication will the authenticated users be assigned some aruguments like SessionToken. The reason I ask is because I want to understand the backend processes and the differences between what is currently present and how it will be after the claims based authentication. Also are there any documents around this which you can direct me to. I also wanted to understand that by "way forward" did you mean it is a scalable solution?

    2) Probably should be done in AD, this isn't something that is going to be passed in a claim.  You could create a webpart that looks directly at the user's AD account and provides the information, though.

    3) Again, would require a custom webpart or 3rd party webpart.

    4) Not really SharePoint-specific, you would have to have logic, likely in FIM, to do this, but I haven't used the FIM SSPR.

    5) Which Web Service are you talking about here? - I meant the web service that the FIM sends the AD information to. Usually FIM sync service syncs from one directory to another directory. But in this case it will be sending information from one directory to a web server, which is the partner website. Can the FIM send it to a webserver?  And for this to work do we need to configure VPN or can this communication by the VIM server from one AD to the webserver happen over port 443 only?

    I once again thank you for taking the time out to answer my questions. I am not knowledgeable on these products and thus these questions.

    Regards


    Thursday, November 21, 2013 1:14 PM
  • By way forward, I mean that "Classic" (non-claims) is deprecated. It is still possible to use in SharePoint 2013, but requires PowerShell to set up the Web App with Classic auth.

    So for the User Profile web service, you'll want to look at leveraging the SharePoint Connector for FIM and set up the UPA to use an External Identity Manager.  Search for External on my site and you should find the details.  Note that I believe the Connector is not RTW yet, and you will want to contact the program owners (their email is listed on the Connect site) about using it in production. If you're not referring to the UPA, then the web service would have to be able to consume what you're sending, which may require custom development of a management agent.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, November 21, 2013 6:01 PM
  • Hi Trevor

    Thanks for this again. I shall go through the page on your site and will let you know if I have any questions.

    Thanks again for your help and cooperation.

    Regards,

    Tuesday, November 26, 2013 12:23 AM
  • Hi Trevor

    Thanks for your response again. The requirement has changed and since the question has been marked as an answer I shall open a new question. 

    Thanks again for your help. Very much appreciate you helping me. I apologise for the delay in responding. Had a lot of firefighting to do :(

    Regards,

    Dipan

    Friday, December 6, 2013 3:56 AM