There are a few options. 1. The client could use `prompt=login` in the authn request. This would kill SSO because the app would always require authentication. 2. Use the [Post Authn](https://gluu.org/docs/gluu-server/4.5/admin-guide/custom-script/#post-authn) script to check the client_id from the request (and possible lookup the client entity in the database), and based on that, you can require a certain set of allowable acr's. 3. In the application itself, check the `acr` of the id_token, and if it's not what you want, then resend for authn using `prompt=login&acr_value=xxxx`

Hi Mike, For number 1 and 3, we are using SAML TR and mod_auth_openidc in our customer environment, as such, we can't customise the authn request. For number 2, how can we associate the Post Authn script with SAML TR? Do you have a sample script for Post Authn to step up the authentication? Thank you.

I asked @Yuriy.Zabrovarnyy if he has a sample. I don't see one in the [Jans Docs](https://docs.jans.io/v1.1.2/admin/developer/scripts/post-authentication/) either

Actually that doc has link to sample script: https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/postauthn/postauthn.py In-lined comments hopefully make it clear how to use the script.

For stepped up sample I guess we used UpdateToken and PersonAuthentication scripts. Here is doc https://gluu.org/docs/gluu-server/4.5/admin-guide/stepped-up/#step-d-stepped-up-authentication

In jans we have this recipe with digrams which might be easier to read https://docs.jans.io/v1.1.2/admin/recipes/stepped-up-authn/

Min Khang, Just to be clear, I'm assuming both your applications are SAML applications. We're going to look into this, and will revert by tomorrow. It's a little trickier if both the RPs are SAML. BTW, your numbering is a little off in those diagrams, and they are kind of hard to follow. I suggest using the free service [sequencediagrams.org](https://sequencediagrams.org) for these types of diagrams, and add the tag `autonumber`

Hi @Michael.Schwartz There is a mixture of mod_auth_openidc and SAML applications in customer environment. Currently there isn't any OpenID Connect client in the environment. I see the documentation shared by @Yuriy.Zabrovarnyy, it looks like it will involve modifying the authorize call with the IDP, which doesn't seem feasible with mod_auth_openidc and SAML applications. The current implementation is we have a Person Authentication Script to check the User Role and the Application accessed to determine if the user is required to perform second factor authentication. ``` title Single App OTP actor "User\nJIRA User\nTAG Admin" as User materialdesignicons F08C6 "TAG\nmod_auth_openidc\nApp" as TAG #green materialdesignicons F1577 "Gluu SSO IDP" as Gluu autonumber 1 User->TAG: Access TAG Application TAG->User: Reverse Proxy redirect to IDP Login User->Gluu: SSO Login activate Gluu Gluu->User:New Session\nPrompt Login User->Gluu: Enter username/password Gluu->Gluu: Check if user is\nAdmin for TAG Gluu->User: User is Admin\nPrompt OTP Page User->Gluu: Enter OTP Gluu->User:Successful Login\nOIDC Redirect to TAG deactivate Gluu User->TAG: Access TAG Application ``` This Person Authentication Script is working until the user is accessing another application on the same SSO session, which bypasses the Person Authentication Script ``` title Multi-App OTP actor "User\nJIRA User\nTAG Admin" as User materialdesignicons F08C6 "JIRA\nSAML App" as JIRA #blue materialdesignicons F1577 "Gluu SSO IDP" as Gluu materialdesignicons F08C6 "TAG\nmod_auth_openidc\nApp" as TAG #green autonumber 1 User->JIRA:Access JIRA Application JIRA->User:SAML Redirect to IDP Login User->Gluu:SAML Login activate Gluu Gluu->User:New Session\nPrompt Login User->Gluu: Enter username/password Gluu->Gluu: Check if user is\nAdmin for JIRA Gluu->User: Successful Login\nSAML Redirect to JIRA deactivate Gluu User->JIRA: Access JIRA Application note over User: <align:center>A few\nmoments later</align> User->TAG: Access TAG Application TAG->User: Reverse Proxy redirect to IDP Login User->Gluu: SSO Login activate Gluu Gluu->Gluu:Validate\nSSOSession Gluu->User:SSOSession Validated\nRedirect to TAG deactivate Gluu User->TAG: Access TAG Application ``` So our idea is to be able to invalidate the SSOSession if the User is determined to be a Admin of the Application accessed.

Is it question about step 12 to decide whether to invalidate AS session ? `post-authn` script is invoked on each call to Authorization Endpoint (`/authorize`). It means that on step 11 to Authorization Endpoint `post-authn` script can intercept call and in script you can invalidate server session if needed. Script provides access to session and request objects. Example: ``` def forceReAuthentication(self, context): session = context.getSession() request = context.getHttpRequest() if (<condition for invalidation>): # if True is returned server invalidates session and redirects for authorization return True return False ```

Hi @Yuriy.Zabrovarnyy, Yes, we are looking at checking the the user session vs the condition we have set for user to be stepped up. For mod_auth_openidc, I believe we can implement the `post-authn` script in the OpenID Connect Client for the Reverse Proxy. What about SAML Applications? Where can we define the `post-authn` to intercept the `/authorize` call?

`post-authn` script lives inside AS. It has to be assigned to respective client. Each time RP calls AS Authorization Endpoint (`/authorize`) AS checks whether client send in request has `post-authn` script assigned to it (on db level `jansClnt` should have DN of script in `postAuthnScripts` attribute). If yes it invokes script assigned to that client. Client is the entity which represents RP on AS side.

Maybe @Dzouato Djeumen.Rolain Bonaventure could comment here about how this translates in the Shib IDP SAML flow.

Please find attached a sequence diagram for a tentative description of the authentication flow you'd like to achieve. Let me know if you have any questions.

If it's ok, I"m making this issue public because it may be useful for other Gluu 4 end users, and there is nothing customer specific I see here.

Hi @Michael.Schwartz, I've removed references to the customer, you may make it public. @Dzouato Djeumen.Rolain Bonaventure, I can see that the SAML authn flow is also using the post_authn script to handle the session check and triggering re-authn May I know where can we define this post_authn script in Gluu?

Hello Kee Wee, You can find information about the Post Authentication script here: https://gluu.org/docs/gluu-server/4.5/admin-guide/custom-script/#post-authn

Hi, Kee Wee! Do you need any further assistance on this ticket? Let us know if we can close it. Regards ~ Shakil

Hi @Mobarak Hosen.Shakil, Thanks for reminding this ticket. Yes, we see the post-authn script to handle the the session, however, how can we assign this script to the SAML clients? I am seeing that the scripts have to be assign to a OpenID Connect client to take effect and there is no such function or feature in SAML TR configuration.

Hi, Kee Wee! It's possible to attach post authn script with SAML TR. Please apply the following changes: 1. Goto OpenID Clients and find IDP Client 2. Inside IDP Client > Custom Scripts tab > post authn script 3. Select the post authn script you have added Do you have multiple TR in Gluu? All SAML TR usage IDP client for authentication and authorization. Regards ~ Shakil