WARNING!!! I suggest to NOT deploy Hyland IdP if below might apply to you.

[Ryan_Wakefield]

After some recent work and discussions with support, as well as getting confirmation on the post you can find here, I would NOT suggest you consider deploying the Hyland IdP if the following situations apply to you.

If you use AD - Enhanced:

1. If you use something as your username that could potentially change. What I mean by this is if you have a user whose name is Jane Jones (username JJONES) gets a name change and becomes Jane Smith (username now JSMITH), then because the Hyland IdP matches based upon username, one the now Jane Smith logs into the system using the Hyland IdP, then they will get a brand new account created for them and their audit history will now be split between the previous JJONES user account and the new JSMITH user account.
2. If you are a Healthcare customer and have the Epic Integration, then this can make it even messier. This is because with the Epic Integration, when a user accesses an OnBase document from inside of Epic, it will search for their user account based on the username sent over. If it doesn't find it, then it will create a new user. So because of how the Hyland IdP works, and based on a similar example in #1, instead of the audit histories being split, you will now be combining two different audit histories of two completely different people and then you could cause even more issues with any potential future compliance issues. (This one is for you @Aaron Truskot .)
3. Because of how OnBase AD Sync happens, this one is even uglier. So let's say that you have a user in the system that was created through the AD-Enhanced NT Authentication setup, then they are mapped by their SID. However, let's say that you have Jane Jones (username JJONES, who was mapped based upon their SID) have their name changed to Jane Smith (username JSMITH), but they don't log in right away and maybe goes on vacation for a week. During that week you have a new hire come on name John Jones and they get assigned the username JJONES. When John goes to login to OnBase through the Hyland IdP, because the Hyland IdP maps based upon the username, then he will get mapped to the currently existing JJONES (Jane Jones) user account and thus now his audit history will be merged with hers. However, once Jane Smith comes back from vacation, if she logs in using NT Authentication, because she is mapped by her SID, then it will update her account back to the values for her and updated her username to JSMITH. Now you have John Jones login to the system using the Hyland IdP, because the user account JJONES no longer exists it will create a brand new user account for him. Now you have Janes audit history start with her, have a section of John's, then continue with Janes, and finally you have John's audit history starting new as if he never existed in the system yet he did.

I know there are more like the ones dealing with load balancing and security log history on user accounts from @Amber Hudson , but I will let them post about them and anyone else join in on this conversation.

Hopefully Hyland gets this fixed sooner rather than later because the issues I have brought up, and the issues mentioned below, are absolute show stoppers for us except for the handful of users that will HAVE to use the Hyland IdP. Until these issues are fixed, I advise you to very VERY carefully evaluate the problems I have presented as well as the problems mentioned by others below before you go to implement the Hyland IdP.

Another issue I just thought about is how does this affect multi-domain systems? This could make this even MORE uglier than my #3 example.

Thanks.

Tagging people that I know this might affect to spread the word.

@Jim Baad @Rett Alexander @Derek Tucker @Gerri Glines 

[Danielle_Workma]

Ryan, we are currently reviewing and discussing the concerns you posted above. It may take us some time to unpack and analyze, so we appreciate your patience in between updates.

[Ryan_Wakefield]

Thank you @Danielle Workman , I appreciate this information. If it helps, please don't hesitate to reach out to me as I would be more than happy to discuss this with you in more detail and answer any and all questions you might have.

[Ryan_Wakefield]

@Danielle Workman ,

Oh, I guess I should add to my list that the OnBase IdP as well as the Hyland IdP don't respect internal OnBase user/security groups at all. I have found out through testing that if you are assigned to a user group that isn't tied to AD, then when you login through the OB or Hyland IdP you will be removed from that group.

As well, the biggest thing that I hate so much is the fact that the IdP requires the security group names to match exactly to what is inside of OnBase. One of the biggest benefits of moving to the AD - Enhanced setup was the ability to map user groups to AD security groups, even if the name didn't match exactly. This just meant it was that much easier to map as well as reduced the amount of security groups a person was in inside of AD. It also meant that we didn't have to go and create special OnBase security groups to match the names inside of OnBase.

Those are the other two big issues I have with the IdP overall. Just simply put, it doesn't integrate or play well with OnBase at all. I feel like in a way I have gone back to the days of AD - Basic.

Thanks.

[Amber_Hudson1]

Thanks Ryan for posting this, we currently have IdP implemented but it does present some interesting issues:

1. When authenticating into the Unity Client using IdP our users tend to lose their workview "enable always on" settings, it only holds onto the last one they had open this is annoying more then system limiting

2. We had some load balancing issues using user groups because when the user would authenticate in it would remove them and add them back in to their groups causing them to be removed from the load balancing (we did work with support and have this semi fixed currently)

3. We currently are having issues where the cache on the OnBase side holds onto previous values and then will not let the user log in because it claims the headers are to long, we have to go manually remove all cookies for the Hyland site to get them back in.

These are the 3 main things I run into consistently in addition to the issues Ryan has listed above.