Security engine for Java (authentication, authorization, multi frameworks): OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...

Added a new Maven module with SAML clients able to be initialized from a relational database. There is quite a lot of duplicate code between PAC4J-SAML and PAC4J-SAML-DB, further changes are assumed that should remove most duplicates.

This adds and documents a CouchDB authenticator and fixes #902.

The tests in the current state of the PR require a CouchDB server running on http://localhost:13598 so I think it still needs some more work to find a proper CouchDB mocking. But I'm opening the pull request to see if you have some comments other than this one...?

Hello everyone,

while using Pac4j for SAML Delegate Authentication in CAS, I have encountered a problem when extracting complex type attributes from SAML2 assertions. After checking with the Pac4j codebase, I have noticed that there is no differentiation at all and the value is just being extracted by calling dom.getTextContent(), which stuffs all attribute values from complex types into one long string.

Example:

    <saml:AttributeStatement>
      <saml:Attribute Name="Foo">
        <saml:AttributeValue xsi:type="xs:string">Bar</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="Organization"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue>
          <OrganizationType
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:q1="urn:osp:foo:schemas:identity"
            xsi:type="q1:OrganizationType"
            id="ab417e71-3fe8-4981-d629-08d90ef68525">
            <q1:OrganizationName q1:attributeId="urn:osp:foo:attribute:organizationName">Example Corp</q1:OrganizationName>
            <q1:EmailAddress q1:attributeId="urn:osp:foo:attribute:emailAddress">[email protected]</q1:EmailAddress>
            <q1:Address q1:attributeId="urn:osp:foo:attribute:address">
              <q1:Street q1:attributeId="urn:osp:foo:attribute:street">Example St</q1:Street>
              <q1:StreetNumber q1:attributeId="urn:osp:foo:attribute:streetNumber">123</q1:StreetNumber>
              <q1:City q1:attributeId="urn:osp:foo:attribute:city">ExampleCity</q1:City>
              <q1:ZipCode q1:attributeId="urn:osp:foo:attribute:zipCode">123456</q1:ZipCode>
              <q1:Country q1:attributeId="urn:osp:foo:attribute:country">ExampleCountry</q1:Country>
            </q1:Address>
          </OrganizationType>
        </saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>

While the attribute Foo is extracted without a problem, the attribute Organization with it's complex value type is extracted as one large text with line delimiters. After extraction with the current code base, printing the results looks like this:

Foo=Bar
Organization=
          
            Example Corp
            [email protected]
            
              Example St
              123
              ExampleCity
              123456
              ExampleCountry

I have implemented a more forgiving extractor. With it the output looks a little better:

Foo=Bar
OrganizationName=Example Corp
[email protected]
Street=Example St
StreetNumber=123
City=ExampleCity
ZipCode=123456
Country=ExampleCountry

What do you think?

Cheers

Here is a less complex fix for #695 than #696 :)

I still made some changes on some of the other exceptions, but everything stayed runtime exceptions.

Everything is explained in the commit messages, it is similar to #696 in terms of behaviour, I made some improvements here and there.

Here is a PR for #617 :)

I added the matches method to PasswordEncoder. I added three password encoders: one for Spring, one for Shiro and one for jBcrypt.

I updated MongoAuthenticator and DbAuthenticator to take advantage of the matches method.

At first I wanted to update also StormpathAuthenticator (which extends AbstractUsernamePasswordAuthenticator like the other two), but it seems to me that StormpathAuthenticator really only need the Encoding part of the PasswordEncoder, the matching seems to be handled by the Stormpath library itself. Thus I really wonder if it makes sense to encode the password in the StormpathAuthenticator! But this is out of scope of the current PR, I can open an issue if you want.

When sending a SAML2 logout response to a service, the IdP can respond with urn:oasis:names:tc:SAML:2.0:status:PartialLogout because it was unable to contact all participating services (SLO). The session has been terminated on the IdP however and since the logout request was initiated by the service, it may be ok to continue the flow even when SLO is not configured properly somewhere else.

This changeset introduces a new SAML2 client property, allowing to treat PartialLogout responses like a Success, if configured explicitly. The default behaviour is not changed for now, although it would probably make sense, because the logout process between Pac4j-Service and IdP is still successful in the described case.

When OIDC OP produces an access token as JWT, pac4j must be able to extract those claims as well, after verifying the AT. Currently, only ID token claims and profile claims are collected into the profile.

I know you guys said you won't accept a kerberos implementation for whatever reasons.. But I wanted to make sure that the work I've done is somewhere. We are using a 1.8 pac4j version of this with our clients. The rationale in my mind for this is as follows. We create software that's distributed to multiple clients and each of them have there own security requirements. Our software allowed them to configure in the kind of security they want and we're using pac4j as that library. Even though kerberos may be supported via other mechanisms using pac4j as the common integration layer provides value for us. I'm not sure how to implement unit tests yet and until I know you're going to include it there's no point making the effort.

• Adds an optional boolean flag to the default security logic to not load profiles from the session and instead loop through the existing clients to renew the user profile. The default behavior is as it was before, without change.
• Add test cases to verify behavior.

Added a short Read Me text file with steps to follow in order to use PAC4J against ADFS. Modified SAML2 response validation. NameID is not needed if at least one Subject Confirmation is present (even without a NameID). BaseID is also accepted. If NameID is empty, a dummy NameID is used for SAML2 credentials.

EDIT: see comments below, this has been rebased on top of #697

A fix for #695

It became MUCH bigger than what I expected at first.

The thing is that I found myself needing to differentiate between expect exception (such as bad formatted client request, invalid credentials, missing information, unexisting accounts) and unexpected exception (such as multiple accounts in the db, problem connecting to the remote authenticator provider, etc).

So I made CredentialsException extends Exception instead of TechnicalException, I made MultipleAccountsFoundException extends TechnicalException, and then I had to make OAuthCredentialsException extends TechnicalException too because the OAuth client is not a IndirectClientV2 and does not use the Authenticator abstractions.

Then because CredentialsException became a checked exception, I had to change a lot of things in many places, mostly tests.

I took this opportunity to add a few improvements in the LocalCachingAuthenticator so that it rethrow the original exception and not the cache's ExecutionException. I also improved (but please check it is correct) the JwtAuthenticator to throw a CredentialsException instead of a TechnicalException when the JWT token can't be parsed, because it is expected that client could send wrong data. The opposite happened with the StormpathAuthenticator that was throwing a BadCredentialsException when it had a problem connecting to Stormpath.

This changes the API of Authenticator because now it can throw 2 checked exception in validate. The same for CredentialsExtractor (maybe in its case, an exception for bad format could be introduced instead of using the generic CredentialsException by the way...).