SAML IdP-initiated Single Sign-On

[Matthieu Taggiasco]

Hi everyone,

I tried to find out if the IdP-initiated SSO is possible with Pac4j. 

The principle is the following : the user connects to IdP and then is redirected to the SP with a SAMLResponse. So there is no AuthnRequest, no cookie, nothing. It's like if the user never went to the SP before that call. 

As far as I can see, the defaultUrl can be set with the CallbackController definition. Is that enough for an IdP-initiated SSO ? Do you see anything that would not work ?

Thanks,

Matthieu

[Jérôme LELEU]

Hi,

Yes, you can, though it may depend on the capabilities of the client.

You have two kinds of logout initiated by the IdP: the back-channel one and the front-channel one (CAS, OpenID Connect, maybe SAML...)

We previously had an application logout filter, it is now turned into a logout filter (based on the DefaultLogoutLogic) which handles both cases (see: https://github.com/pac4j/pac4j/pull/764).

This logout filter can be configured to perform a local logout or redirect to the identity provider for performing the central logout which makes a back-channel or front-channel logout for the application.

The front-channel logout call from the IdP can be generally handled by the logout filter configured to perform a local logout. The back-channel logout call is generally received on the callback endpoint and requires that the client knows how to handles this kind of call (because if refers to specific protocol data: service ticket in CAS for example).

The CAS support handles both for example, though the front-channel and back-channel calls are both handled on the callback URL.

Here is the updated documentation for logout from the j2e-pac4j library:

6) Logout (LogoutFilter)

The LogoutFilter can handle:

• the local logout by removing the pac4j profiles from the session (it can be used for the front-channel logout from the identity provider in case of a central logout)
• the central logout by calling the identity provider logout endpoint.

It has the following behaviour:

1) If the localLogout property is true, the pac4j profiles are removed from the web session (and the web session is destroyed if the killSession property is true)

2) A post logout action is computed as the redirection to the url request parameter if it matches the logoutUrlPattern or to the defaultUrl if it is defined or as a blank page otherwise

3) If the centralLogout property is true, the user is redirected to the identity provider for a central logout and then optionally to the post logout redirection URL (if it's supported by the identity provider and if it's an absolute URL). If no central logout is defined, the post logout action is performed directly.

The following parameters are available:

1) defaultUrl (optional): the default logout url if no url request parameter is provided or if the url does not match the logoutUrlPattern (not defined by default)

2) logoutUrlPattern (optional): the logout url pattern that the url parameter must match (only relative urls are allowed by default)

3) localLogout (optional): whether a local logout must be performed (true by default)

4) centralLogout (optional): whether a central logout must be performed (false by default).

An example of configuration:

<filter>

    <filter-name>logoutFilter</filter-name>

    <filter-class>org.pac4j.j2e.filter.LogoutFilter</filter-class>

    <init-param>

        <param-name>defaultUrl</param-name>

        <param-value>/?defaulturlafterlogout</param-value>

    </init-param>

</filter>

<filter-mapping>

    <filter-name>logoutFilter</filter-name>

    <url-pattern>/logout</url-pattern>

    <dispatcher>REQUEST</dispatcher>

</filter-mapping>

<filter>

    <filter-name>centralLogoutFilter</filter-name>

    <filter-class>org.pac4j.j2e.filter.LogoutFilter</filter-class>

    <init-param>

        <param-name>defaultUrl</param-name>

        <param-value>http://localhost:8080/?defaulturlafterlogoutafteridp</param-value>

    </init-param>

    <init-param>

        <param-name>localLogout</param-name>

        <param-value>false</param-value>

    </init-param>

    <init-param>

        <param-name>centralLogout</param-name>

        <param-value>true</param-value>

    </init-param>

    <init-param>

        <param-name>logoutUrlPattern</param-name>

        <param-value>http://localhost:8080/.*</param-value>

    </init-param>

</filter>

<filter-mapping>

    <filter-name>centralLogoutFilter</filter-name>

    <url-pattern>/centralLogout</url-pattern>

    <dispatcher>REQUEST</dispatcher>

</filter-mapping>

Does it make things a bit clearer for SAML?

Thanks.

Best regards,

Jérôme

--
You received this message because you are subscribed to the Google Groups "pac4j-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthieu Taggiasco]

Hi,

I was maybe not clear enough. I'm not talking about logout, but the login process.

I discovered yesterday there was a use case in SAML where the login is initiated by the IdP. In such a case, the SP directly receives the SAML response (there is no SAML AuthnRequest). It's also called "Unsolicited response". 

The question is : are there any restrictions in the callback logic, such as "check the context to be sure the user already came here" or "check if the AuthRequest has already been sent" and so on.

Thanks,

Matthieu

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users...@googlegroups.com.

[Jérôme LELEU]

Hi,

No, it's me. Indeed, you were talking about login, not logout...

In fact, I don't know, Misagh certainly does.

Did you test it?

Thanks.

Best regards,

Jérôme

To unsubscribe from this group and stop receiving emails from it, send an email to pac4j-users+unsubscribe@googlegroups.com.

[Misagh]

On Thu, Dec 8, 2016 at 12:54 AM, Matthieu Taggiasco <ma...@taggiasco.ch> wrote:

Hi everyone,

I tried to find out if the IdP-initiated SSO is possible with Pac4j. 

The principle is the following : the user connects to IdP and then is redirected to the SP with a SAMLResponse. So there is no AuthnRequest, no cookie, nothing. It's like if the user never went to the SP before that call. 

As far as I can see, the defaultUrl can be set with the CallbackController definition. Is that enough for an IdP-initiated SSO ?

​Yes.

​

Do you see anything that would not work ?

​Nope. Post back if you run into any issues please.

[Matthieu Taggiasco]

Hi,

I've just made a test and it looks ok. I should have tested it before posting a message ! ;-)

Best regards,

Matthieu

[Jeffrey Wang]

Hey,

Do you think you can show me an example code of processing an IdP initiated SAML response with pac4j? I'm trying to do the same thing, but I'm not sure how.

[neerajve...@gmail.com]

Do we answer for this. I am facing issue with error  as My okta saml doesn't have SPSSO descriptors  it has onlt IDSSO descriptors

Caused by: org.pac4j.saml.exceptions.SAMLException: Cannot find entity org.pac4j.saml.metadata.SAML2ServiceProviderMetadataResolver@43e56bf2 in metadata provider

        at org.pac4j.saml.context.SAML2ContextProvider.addContext(SAML2ContextProvider.java:125)