Skip to content

Summary of updates for 3.1.4

Jump to bottom
Jose edited this page Aug 22, 2018 · 18 revisions

This page contains info about the status of project as of Aug 16th.

Most prominent changes

We can use the contents of this section to feed 3.1.4 docs branch.

Not all changes/details are listed here:

Specifying location of logo image

See https://github.com/GluuFederation/gluu-passport/issues/36 , https://github.com/GluuFederation/gluu-passport/issues/34

So via oxTrust, a property named logo_img is added to the strategy pointing to image location

openidconnect support added

See https://github.com/GluuFederation/gluu-passport/issues/36

From our earlier ticket experience, we are bundling passport with this new strategy.

It is expected the strategy has the following properties filled in (in oxtrust): issuer, authorizationURL, tokenURL, userInfoURL, clientID, clientSecret, and optionally acr_values

I confirmed only code flow is supported. Also only confidential oauth clients (no secretless ones).

No restarts needed more

See https://github.com/GluuFederation/gluu-passport/issues/12 , https://github.com/GluuFederation/gluu-passport/issues/35

any changes applied to strategies via oxtrust (or ldap) requires to wait 1 minute. Passport re-reads the config automatically

The token that protects the oxtrust passport web service has expiration. No need to restart for passport so that it can get a new token

Logging

See https://github.com/GluuFederation/gluu-passport/issues/32 , https://github.com/GluuFederation/gluu-passport/issues/33

Logging level is parameterizable now. See below.

Some log statements have been removed, others added, etc. all aimed at improving. Still needs more work

A new log file is created every day not hour

To add a log statement one does the following:

  • import logger if not present already: var logger = require("./utils/logger")
  • logger.log(<level>, <message>, more params...) or logger.sendMQMessage(<message>, more params...) or logger.log2(<level>, <message>, more params...). The last one adds a log statement to both passport log file and Message Queue if defined. This is the preferred way among the 3

Example: logger.log2('verbose','%s planets crashed on %s', 3, 'Sept 31th')

Flow

See https://github.com/GluuFederation/gluu-passport/issues/38 , https://github.com/GluuFederation/gluu-passport/issues/39

The cust script was written from scratch

IDP selection

This is about https://gluu.org/docs/ce/authn-guide/inbound-saml-passport/#generation-of-suitable-authorization-urls (when no form to select the provider is shown)

For the state discussion we had, the cust script now uses an optional property: authz_req_param_provider which if used, must be the name of an already existing oxauth custom parameter for authorization request (see oxauth#647)

In this parameter, the provider name can be passed as it used to be in state.

If "behaviour" parameter is used (see "social and saml" below), only suitable social/saml providers are deemed valid.

Step 2 was re-introduced

See #39.

These 2 new properties can be used in strategies:

  • "emailLinkingSafe". If set to true allows an unknown user coming, be correlated to an already existing account if the email in remote IDP matches the one in local Gluu LDAP
  • "requestForEmail". If set to true a page will be shown to fill email value if the profile in remote IDP does not contain (or release) such attribute

Currently, enough validations are in place to make impersonation impossible IMO.

Client side does less

The call to /passport/token is done in the cust script, not the login page. Also, the redirect to passport URL that triggers the remote integration is called from the cust script too, not the page.

Providers are checked

See https://github.com/GluuFederation/gluu-passport/issues/25 Passport went crazy when passing an inexistent provider. Validations were added

Social and SAML

The cust script copes with both social and saml providers at the same time. It identifies if the provider is a SAML IDP or not. If changes are made to providers' list or providers' config, whether social or not, the scripts picks it.

A new custom script property was added: "behaviour". If equal to "saml", only IDPs will be shown on the right pane. If equal to "social" only defined social strategies (in oxTrust) will be listed. Otherwise (or if not set), both saml + social providers appear.

As discussed in group chat, two acrs still remain (passport_social and passport_saml). So there are 2 identical script that differ on "behaviour" only.

Multivalued attributes support

Profile coming from external IDP can contain multivalued attributes and this will be handled correctly. More exactly, the json representation of profile in js file of strategy (eg twitter.js) can build something like:

{
 id: "1234",
 memberOf: [
    "bartender",
    "pooldancer",
    "doorman"
  ]
}

Updating of profile

If an already existing user is logging in, attribute values coming are thoroughly replaced. Example:

User Will logs in, and ldap ends up this way:

uid: willow234
displayName: Will
attribute: value1

User Will changes his attribute in the social network to [value0, value2] (e.g. in case of multivalued attr), and logs in again. It ends up like this:

uid: willow234
displayName: Will
attribute: value0
attribute: value2
Clone this wiki locally