Arize-ai / phoenix

AI Observability & Evaluation
https://docs.arize.com/phoenix
Other
4k stars 295 forks source link

[ENHANCEMENT] Filter SSO users #5333

Open stdweird opened 1 week ago

stdweird commented 1 week ago

Is your feature request related to a problem? Please describe. An additional filter that has the effect that only a subset of all possible SSO users can actually login. See discussion in https://github.com/Arize-ai/phoenix/issues/4980#issuecomment-2470266035

Describe the solution you'd like Ideally some generic solution using a plugin and a way to override the default SSO handling, that would give total configurability (like determining besides plain access if the user is a member or an admin). But for starters, eg an environment variable that is used as a (case insensitive) regex pattern that checks if the email matches the pattern (and upon match, allow login to proceed). (For the admin vs member role, a 2nd variable to match admins; applied after the first filter i also a solution).

Describe alternatives you've considered Setting up eg a registered app in azure portal coupled to an AD group is probably the best way to go, but is far from a light procedure. Also not clear how to determine in that scenario if a user is an admin or a member.

Additional context RBAC where teams exists that have members and admins, and where teams have access to certain projects is the best way (then a single SSO to login is ok; access to projects is them based on team membership and role in the team).

axiomofjoy commented 1 week ago

Hey @stdweird, not sure if this is what you are looking for, but we recently added experimental plugins under the PHOENIX_FASTAPI_MIDDLEWARE_PATHS, PHOENIX_GQL_EXTENSION_PATHS, and PHOENIX_GRPC_INTERCEPTOR_PATHS environment variables that allow users to add custom middleware to Phoenix. This feature is still undocumented, but the upshot is that you would define your custom middleware and then make it available to Phoenix via a volume mount or by building a custom Docker image containing your middleware using our Docker image as the base image.

Minimal example below (does not include gRPC):

from strawberry.extensions import SchemaExtension

from starlette.middleware.base import BaseHTTPMiddleware

class CustomSchemaExtension(SchemaExtension):
    def resolve(
        self,
        _next,
        root,
        info,
        *args,
        **kwargs,
    ):
        print("Before resolve")
        return super().resolve(_next, root, info, *args, **kwargs)

class HeadersMiddleware(BaseHTTPMiddleware):
    async def dispatch(
        self,
        request,
        call_next,
    ):
        response = await call_next(request)
        print(f"{response.headers=}")
        return response

Run with

docker run -it -v /Users/xandersong/Desktop/phoenix-extensions:/extensions -e PHOENIX_FASTAPI_MIDDLEWARE_PATHS=/extensions/extensions.py:HeadersMiddleware -e PHOENIX_GQL_EXTENSION_PATHS=/extensions/extensions.py:CustomSchemaExtension -p 6006:6006 arizephoenix/phoenix:latest
stdweird commented 1 week ago

@axiomofjoy well, it might; but i am unfamiliar with starlette so it will take some time to find out where to insert extra user validation. but at least this opens the way for monkey patching ;)