Hi, Abhinay. It would be better if you would provide a step-by-step detailed description of how such flow will proceed (how you see it working), explaining, in particular, what do you mean by next sentence: "Gluu server needs to protect". In a nutshell, there is a bunch of SSO protocols (like OpenID Connect, SAML, CAS) and an authorization prtocol (UMA) web services with restricted content may use to communicate with Gluu Server and either get a set of user's personal attributes from it, or in case of UMA get a final authorization decision - but it's responsibility of the web service where content is to enforce some access policy after that. At no point in any flow Gluu Server actually enforces authorization decision or handles requests **for the protected resource itself** - it at best provides enough data for the resource's hoster to decide whether allow the access, or not.

Thank you for your reply! Here is a step-by-step description of the flow (as I would like to see it working): 1. An end user tries to access a URL: http:<name>:<port>/<endpoint> (which can correspond to a service endpoint). 2. When the URL is entered, the end user is redirected to the Gluu login page. 3. On entering the user's credentials, Gluu server redirects him back to the URL that the user previously attempted to access. 4. Having completed the authentication, end user successfully accesses the URL. Is there a way to do this in Gluu server?

Outside the scope of community support.