University of South Wales: Cyber University of the year: Four years running: 2019, 2020, 2021, 2022

In PingFederate, we can release attributes at three layers (remember the mnemonic CAP)

CONNECTION – ideal for Federated SSO, at Nation state level, or for Education

ADAPTER – specific attributes from an LDAP or AD datastore

POLICY – Dynamic, realtime, can alter depending on the time

 

In Federated SSO, generally SP’s in the UK require the release of a single attribute called eduPersonScopedAffiliation for authorisation. The left hand just needs to state “member”, as that includes students and staff. 

The right hand syntax is the base domain of the University eg hogwarts.ac.uk.

 

Together the EPSA attributes look like this:

member@hogwarts.ac.uk

student@hogwarts.ac.uk

staff@hogwarts.ac.uk

student@hufflepuff.hogwarts.ac.uk

 

PingFederate. 11.3 – How to release the base attribute the lazy way

As member includes all other attributes, we can easily add this in as text. There’s no need to query the datastore.

Step 1 – Adapter

The HTML form adapter, provides a login page to the user, to enter username and password. The PCV (Password Credential Validator) for this adapter, this will query the datastore to check the users password and authenticate them.

There is no need to add in EPSA as an attribute at the Adapter Level.

In this screenshot the HTML Form Adapter > Extended Contract > You’ll notice that EPSA is not under the Extended Contract for additional attributes to transmit to the SP.

.

 

Next we come to the Authentication > Policies

Under Success > Select the “Contract Mapping” link

 

Step 2 – Contract Mapping Link

Here’s the cheat code. member@hogwarts.ac.uk (Text).

This means you always transmit/release the base EPSA scope for the university.

Authentication > Contract Fulfillment (2nd tab).

Here we see a mix of the source being the adapter or Text.

For EPSA, we select the drop down that states “Text”, and type in “member@hogwards.ac.uk”

That’s it! The cheat code!

 

EPSA can be a multiple value array, ie it could include member@hogwarts.ac.uk, member@hufflepuff.hogwarts.ac.uk, and member@divination.hogwarts.ac.uk.

If every student has access, then you only need member. But the beauty of this, is that you can just type in the other scopes if you wish.

 

 Step 3 -What about the SP Connection side? Applications > SP Connections

Under IAMSHOWCASE connection, we’ve added eduPersonScopedAffiliation as an attribute for the SP side.

 

Step 4 – Test the SP Connection > SSO Application Endpoint URL

This URL will transmit the attributes to IAMSHOWCASE, so that you can see they are being released.

Firstly the user sees a login page.

This is actually the HTML Form Adapter – which presents a login page to users, even if the app doesn’t have an actual login page. It takes the username entered and uses a PCV to look up the user’s attributes in a LDAP/AD data store (but not the EPSA attribute).

IAMSHOWCASE shows us the received EPSA attribute – and it has multiple values, which is wonderful!

There are 8 limited left hand syntax.  They’re mandated.  Only use these.  See the UKFED list below to make sure you’re using the correct syntax.  Failure to use the correct syntax, means a failure to be authenticated by the SP.

 

In summary, EPSA (as an attribute,) can be added as Text, under the Policy > Contract Fulfilment tab.

As this is static text, it will be released for everyone, therefore the base scope is best, the base scope is “member@hogwarts.ac.uk”.

 

References:

UKFED EPSA

https://www.ukfederation.org.uk/content/Documents/AttributeUsageNotes

https://docs.ukfederation.org.uk/trp/1.5/attribute-usage/

Recently I was asked to discuss what is a “default device” in P1SSO MFA, so I took a deeper dive, and found some interesting results.

The First device registered for a user is considered the “default device”.

However, that doesn’t mean that device will be used by P1SSO. So what is P1SSO doing under the hood, in order to select the default device?

1. First, an ordered list of devices is compiled for that user, (eg SMS OTP, Email OTP, Mobile Push OTP).
2. A venn diagram of devices (methods) for both the authn policy and the mfa policy are compared. What are the common methods allowed (methods such as SMS, Email and Mobile) for both the authn policy and the MFA policy. For this instance we go with SMS OTP, as this is allowed by both policies.
3. Next, PingOne looks for “Blocked devices” and removes them from the ordered list, and reorders the list of devices for the user.
4. Lastly it checks to see if MFA is to be sent direct to a device, or a list of all devices is presented to the user. The OTP won’t be sent, until the user selects SMS.

This means, that even where SMS is selected as the default device, the OTP might be sent via email. Why?

SMS is listed as “blocked or locked”

If the SMS device is blocked, the SMS device will be removed from the ordered list of devices for the user, and the list reordered to REMOVE SMS.

P1SSO MFA knows it can’t use SMS to send an MFA, so it has to find a different way. What’s next?

If Email OTP is unblocked, it might choose Email. The user would have the OTP via Email.

Reference:

View at Medium.com

View at Medium.com

View at Medium.com

Azure AD doesn’t work the same way as legacy Active Directory. Many attributes that are expected, such as employeeid, are not released by default.

In Azure the employeeid attribute can be obtained using the Graph and custom attributes, or via powershell.

Here’s an excellent video which explains how to release employeeid in Azure

Check the token in jwt.io or jwt.ms, to ensure it contains your custom attribute.

Any attributes that are null, will never appear in a token.

This video covers setting up a test Azure OIDC Sample App for testing.

This next video shows the difference between an Access Token and the ID Token.

Access Token = claims related to the App

ID Token = identity of the user

When FIDO creates a Public/Private key pair for a device, a user and a service (its a 3 way authentication), the Public key is sent to the service. How does the device know how to do this?

Step 1 – Metadata Service FIDO operates a Metadata Service.

The FIDO Vendor supplies Metadata, as part of FIDO certification.  This metadata is held on the Metadata Service, which is pulled in by a FIDO Server on a regular basis.  

 

The DEVICE sends a PUBLIC key to the FIDO server, which uses the pulled in metadata to validate the Crypto key, with information provided by the VENDOR when the device was registered with FIDO.

 

 

So what is happening next?

 

The FIDO server downloads the Metadata from an official URL.

The FIDO server uses a digital signature to ensure the metadata has not been tampered.

The metadata cites all the authenticators known to FIDO (checks the Integrity and Authenticity of the metadata).

 

Step 2 – The Metadata carries revoked and security breach information, along with a Rogue List.

Revoked

Malware can bypass security

Rogue List

Reference:

FIDO Metadata URL

https://fidoalliance.org/specs/mds/fido-metadata-service-v3.0-ps-20210518.html

Biometrics URL

https://fidoalliance.org/specs/biometric/requirements/

When you use FIDO registration you are using a Public/Private key pair, but for the device, and only for a single service and user account.

 

WebAuthn let users authenticate with two types of authenticators:

• Roaming authenticators are removable and cross-platform, like a Yubikey, and can be used on multiple devices. To authenticate with a roaming authenticator, you need to connect it to the device (through USB, NFC, or Bluetooth), provide proof of presence (by touching it, for example), and optionally provide user verification, for example, by entering a PIN.

• Platform authenticators are attached to a device and only work on that device. Some examples are MacBook’s TouchBar, Windows Hello, iOS Touch/FaceId, and Android’s fingerprint/face recognition. Biometric data is stored on the device and never sent to the server. When biometrics cannot be used, alternative authentication methods are usually provided. For example, if you are wearing a mask, instead of using Face ID you can enter your passcode.

 

ANDROID FLOW

The default enrollment flow for security keys in Android displayed below and has the following steps:

• Users authenticate with username/password.

• They are prompted to select the authentication method they want to enroll.

• If they pick Security Keys, they are shown a list of instructions.

• They are then prompted to enter their security key.

• The device shows their native UI to complete the security key challenge.

• Users can name the key to later identify it, in case they enroll multiple ones.

 

 

REGISTRATION FLOW

 

Step 1 – User is prompted to choose a FIDO authenticator.  This may appear as a SELECT A METHOD (Email, SNS, Yubikey).

 

Step 2 – User unlocks the FIDO authentication using a finger print reader, a button, a PIN or other method.

 

Step 3 – The DEVICE creates a NEW public/private key pair, which is UNIQUE for the DEVICE, the online service and the USER’s Account.

 

This unique key pair, prevents the keys being shared and reused elsewhere, as the key relates to one browser domain eg Lloyds Bank or Halifax.

 

Step 4 – The Public key is sent to the online service, and associated with the User’s account. (Public key linked to User account).

 

Step 5 – The Private key and BIOMETRICS of the user (for local authentication) NEVER LEAVE THE DEVICE.

 

 

 

Summary

 

FIDO protocols use standard PUBLIC Key Cryptography.

 

Authentication is carried out by the device using the PRIVATE key to SIGN a challenge from the Service.

 

The PRIVATE keys can only be used, after they are unlocked locally on the device by the user.

 

This LOCAL UNLOCK is an action such as a fingerprint reader, a PIN, voice print from a Microphone or a 2nd factor device (Yubi Key) or pressing a button.

 

FIDO Protocols do not provide information that can be used by different online services, to track users.

 

  FIDO2 – Passwordless Fido2 is about removing the username/password, and replacing it with Biometrics.

Instead of a password, users confirm their identity, using biometrics or a pin on a device.

Strong first factor means passwordless.

Enforce Attestation setting (disables self signed certificates)

If you enable this setting, it will require that keys which you are using have a trusted certificate, therefore you will disable security keys which have a self-signed certificate from being used. Enforcing attestation therefore means that during the enrollment process the certificate is checked to confirm if its legitimate and therefore brings in more secure security keys.

Always give the user the option of several methods to select from.  Users often lose their phone, can’t use the selected biometrics, or lose access to the email, so have several back up plans ready.

 

 

 

 

 

 

 

 

PingAccess works similiar to a firewall, it rewrites URL’s and protects the PingFederate server.

Certs > Site > Virtual Host > PA App > Token Provider

Step 1 – Exchange Certificates Step 1.1 – Export the PingFederate certificate for the PF Engine.

Security> SSL Server Cert

Select Action > Export

Certificate Only > Export

Save the cert where’s its easy to find.

 

Step 1.1 – Import the PF Cert into PingAccess

Start from PA Admin Console

Security > Certificates > + to import

Name it eg PF

Choose file > select the PF engine cert > Add

Drag the imported cert from the Cert pane to the Trusted Cert Group pane.

 

Step 2 – Create a PingAccess SITE

PA Admin Console

Sites > + add site

name = PF

Target = https://loadbalancer:443 or https://host:443

Secure = yes

Trusted Cert Group = PF

Save

 

Step 3 – Create a PA Virtual Host The Virtual Host is how PingAccess will access the PF engines.

PA Admin Console

Access > virtual host

Add Virtual host

Host = https://pingfederate_host

Port = 443

Agent cache = 900

Save

 

Step 5 – Create Key Pair for PF host

Security > Key Pairs

Add Key pair

Alias PF Master

Common Name = https://pingfederate_host

Subject Alternative Name = https://pingfederate_host

 

Step 5.1 – Import key pair to the virtual host

PA Admin Console

Networking > Listeners

Engine key pairs pane > change PF Master to the base URL of Ping Access virtual host > Save

 

Step 6 – Match PingAccess Token Provider to PingAccess App

PA Admin Console

System > Token Provider

Host = https://pingfederate_host

Port = 443

Audit = yes

Save

 

Step 7 – Update PF base URL

PF Admin Console (not PA)

System > Protocol Settings > Federation Info

Change BASE URL to the base URL nad port of the PA VIRTUAL HOST > Save

CAUTION: If you get the wrong base URL, PF will be corrupted and you can’t access it.

Double check the base URL.

 

Step 8 – Verify Access from PA to PF

Browser

https://virtualhost:port/pf/heartbeat.ping

You should get a response from PF

Browser

https://virtualhost:port/pa/heartbeat.ping

You should get a response from PA

In Pingfederate 11, the heartbeat can be set to report back live stats about the server.  The Admin console is configured separately from each engine.

The heartbeat URL for the Admin console is:

https://localhost:9999/pf/heartbeat.ping

 

The important question that you’re asking me now, is how do we configure the Admin console heartbeat, and the Engine heartbeat?  Here we go.

Step 1 – run.properties

The default location for run.properties is:

pfinstall > pingfederate > bin > run.properties

Use Notepad++ to open run.properties file > search for heartbeat

By default the heartbeat is set to false, we need to edit this to say true.

Edit heartbeat = true

Step 2 – restart services

 

Step 3 – heartbeat url

The syntax for the heartbeat url is https:// host : port /pf / heartbeat.ping

Note its pf, not Pingfederate.

An example for the Admin Console (on port 9999) would be

https://localhost:9999/pf/heartbeat.ping

This is repeated next on the engines, for a cluster.

 

Step 4 – Templates for the Admin Console.

Pingfederate uses templates for the heartbeat. There are two templates one for the Admin Console and another for Engines. They are both in a default location.

Default Location = pf install > pingfederate > server > default > conf > template

Files = heartbeat.admin.page. template and heart.page.template

 

Admin Template = heartbeat.admin.page.template

The good news is that template updates do NOT require a server restart.

 

Step 5 – Engine Template = heartbeat.page.template

Caution:

Ensure the servers are behind a load balancer, or your server statistics will be publically available.

 

Step 6 – Percentiles (didn’t really see the benefit of this).

You may wish to edit the templates to have percentiles reported.

Default Location = pf install > pingfederate > server > default > data > config-store

File = com.pingidentity.com.monitoring.MonitoringService

Default = 90

Edit Default = 99.9

Template edits do not need a server restart.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OAuth2 has 4 grant types.  Each grant has a different sequence of steps.  Clearly each grant is designed for a different situation. 

This is why Oauth flows confuse people.  The steps and sequence will be different for each flow.

Visual Guide to Flows

The diagram below is the best visual guide to OAuth, that I’ve come across in several years.

The client, makes an authorisation request (via a browser). 

The /authorization end point of the OAuth server, deals with the user login and consent.

Next, the /authorization endpoint sends a code out, to the /callback endpoint of the client.

The /callback is detailed in the redirect_uri parameter. 

An example would be:

GET /callback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24 HTTP/1.1 Host: client-app.com Now communication via the browser stops – and the sequence continues in secret, as server to server communication

 

The Client has a CODE… but the code needs to be exchanged for a TOKEN.

This is what happens in the exchange of CODE for a TOKEN (called an ACCESS TOKEN REQUEST) – Step 4.

It makes a  POST call to the /token endpoint, to make the exchange.

An example would be:

POST /token HTTP/1.1 Host: oauth-authorization-server.com … client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8

 

The /token endpoint of the OAuth server sends token request back to the client – called an ACCESS TOKEN GRANT – Step 5.

An example would be:

{ “access_token”: “z0y9x8w7v6u5”, “token_type”: “Bearer”, “expires_in”: 3600, “scope”: “openid profile”, … }

The Access token grant is FROM to the /token endpoint of the Oauth Server to the client. 

Now all transactions moves to a different endpoint.

 

An API call is made by the client, to the /userinfo endpont of the OAuth server.  The Access Token is sent to the /userinfo endpoint, as evidence, it is allowed access.  

An example would be:

GET /userinfo HTTP/1.1 Host: oauth-resource-server.com Authorization: Bearer z0y9x8w7v6u5

The final step is that user data is returned from /userinfo endpoint, of the OAuth server to the Client, so that the user can be logged in.

 

1. Code Flow

The code flow is the most secure.

Used where the client can keep secrets.

Code is between the Auth Server and the Resource Server.

 

2. Implicit Flow

Immediate Token is sent.  No code is sent.  Gives immediate access.  Used where a client cannot keep a secret, so no point in sending a code, eg a mobile.

PUBLIC CLIENT, as in mobile or web browser.

 

3. Resource Owner

You enter your facebook password into the facebook app on your phone.

You trust the mobile app with your password, as they own the app, a breach isn’t in their interests.

 

 

4. Client Credentials

Used for the client to access its own resources, or information about itself.

 

Reference:

https://everything1know.wordpress.com/2019/06/01/iam-for-dummies-oauth-2-grant-types/ https://portswigger.net/web-security/oauth/grant-types

 

In the oauth protocol, the id_token proves successful authentication by the IDP occurred.

When the scope lists openid, oauth will return an id_token.

• The id_token is in a fixed format.
• The token is in JWT.
• Claims are included, if profile and email are in the scopes requested.

 

How to decode the token?

On the wire, the token is encoded.

Visit jwt.io to automatically decode the token (just paste in the encoded text).

https://jwt.io/

 

Header:

This will usually state type:jwt, alg:rs256,kid=key id

Payload:

The payload contains the user claims and includes several critical fields for troubleshooting, if the authentication has issues. 

• Iss = issuer
• aud= audience ie the app that is to receive the token
• iat = issued at time
• exp = expiry time

Check the iat and expiry time for clock skew at the IDP, particularly, if the IDP’s clocks are ahead of the SP.

Bearer Token

The bearer token, is the equivalent of cash.

Possession of the bearer token is all you need, to get what you want, and cash has no identity linked to it.

The other system is called Proof of possession; however this is not widely used, but acts like a visa card, with an identity linked to it.

 

In Oauth, the Implict flow makes reference to the at_hash. So lets consider this parameter in more detail.

Step 1 – take the access token (we’ll call it x). Step 2 – hash the access token with SHA-256 (we’ll call it Y). Step 3 – take the left hand side of the hashed token Y1 (which is only 128 bits). Step 4 – Base64 encode the left hand side of Y1 (we’ll call it Z).

Step 5 – Z is the at_hash, ie the hash of the access token, after its been hashed with SHA-256, only the first left hand halve of the hash taken, and that half is encoded with Base64 to form the at_hash.

 

The Implict flow spec states that the client MUST validate the SIGNATURE of the ID Token.