A resource is provided to an internal campus group, and over time, it becomes apparent that a small number of external users who are not members of the campus community need to be able to access it.
1) Grant honourary member status to the party and place them in instituional IDM systems, then revoke that membership after it's served the need (unfotunately the need for revocation is often ignored). While this solves the problem of granting access it creates many more. Unfortunately adding users into your IDM system may grant access to many resources and this will most likely be in conflict with licencing conditions for commercial products, many institutes just live with "bending the rules" as far as licencing goes. To do this well, your IDM system needs to be designed to support exception use cases, using approaches like enforcing expiration dates.
2) Create a local account that's not in the IDM system and add the userid as an additonal user of the system in question. While this solves the problem, few systems support a model of granting access to users from institional IDM systems and then adding a "side door" for additional users. This is not recommended, because it creates security holes and access that's rarely revoked.
3) Use federated single sign-on to provide access to the resource to outside parties. Again generally involves the creation of a "side door" onto the system whereby most users directly access the system and the externally users use the federated SSO side door. Also you have the invite problem of how you invite the external user to access the app and how you find out what their idenitifier (e.g EPPN or targetedID) is.