Hi Joao,
> You also refer in the next section "You don't *have* to pick a private key here;". Well, in fact if you don't select a keystore with a private key, when configuring, in step "7.2 - Configure SCIM", the you will not be able to select any other User DN attribute, except cn. If the user suffix is in fact uid, you will not be able to use it! Why? Does this mean that when you connect to an external LDAP you have to use cn= as the User DN attribute since there is no other option?
It should not mean that. I don't know why you're seeing this behaviour. Did you deploy changes after setting up the server connection before using it in the SCIM configuration screens? Maybe that is needed for full access to the server connection so it can load dynamic things (like available attributes) in the UI.
> Regarding IV-GROUPS, and so on, I still don't understand. I am testing the /scim endpoints using curl, but before I login using pkmslogin.form. I don't send any header to /scim/Users/Me or /scim/Users/{Id} and it works fine, and I am not sending any IV-GROUPS, and IV-USER!
Here is the curl command that I am sending and is working fine, as long as the logged in user belongs to the adminGroup.
> curl -v $VERBOSE -s -k --cookie-jar cookie.jar --cookie cookie.jar \
> -H 'Content-Type: application/x-www-form-urlencoded' \
> -H "Accept: text/html" \
> -X GET
https://$HOST/$JUNCTION/Users/$USER_ID \
> --data-ascii ""
Those headers are not coming from your cURL command - they are coming from WebSEAL when it forwards the request to AAC. That's why the junction needs to be configured to send the IV-USER and IV-GROUPS headers. If you don't send those headers on the junction, all authorization and requests will be for the user than you're sending the basic authentication header (also configured on the junction). Probably easuser.
> "the "admin group" name in LDAP and the "admin group" name in AAC user registry must both match the admin group name defined in the SCIM configuration." This is completely new to me. In fact I created a group named "scimAdminGroup", and I don't have it created in the "AAC registry". What I find is that some endpoints are working fine, like /scim/Users but others are not like /scim/Groups. I will give it a try, and see if I change this it will work better. Does this mean that the scim administrator, must be also defined in the AAC user registry? I didn't see this in the cookbook?
I didn't think that SCIM identity assertion from IV headers would work unless the user you're using in Basic Authentication header on junction (probably easuser) was a member of the adminGroup defined in AAC registry AND that group name matched what was in SCIM configuration. Perhaps this requirement has been changed and I am wrong about this now.
@Jasmine Smith may know?
> This the curl command to retrieve the groups:
> curl -v $VERBOSE -s -k --cookie-jar cookie.jar --cookie cookie.jar \
> -H 'Content-Type: application/x-www-form-urlencoded' \
> -H "Accept: text/html" \
> -X GET
https://$HOST/$JUNCTION/Groups \
> --data-ascii ""
> And this is what I am getting back:
> {"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"SCIIS0001E
> The resource 'c2NpbWFkbWluZ3JvdXA' was not found.","status":"404"}
> In this case, the base64 c2NpbWFkbWluZ3JvdXA is in fact scimadmingroup, but when I created this group in embedded ldap it had the name "scimAdminGroup"! Does is mean that the group name must be in lower case only?
I still don't know what is going on here. A request for /Groups should return all groups based on lookup in LDAP - I don't know why it is complaining about not being able to find this specific group or where it's coming from. I don't know if there is a case-sensitivity issue.. I haven't come across it before.
I notice you are sending --data-ascii "" in your GET request... I don't suppose that matters but seems odd. GET doesn't usually have a body.
> As an additional topic, I wish there were some examples to test the functionality of /scim in the cookbook. I am in fact creating a set of scripts to test /scim, like to curl that I showed above, and I will post send them later to you, after everything is working.
Have a look at this course on Security Learning Academy - and the linked 2nd course which talks about POSTMAN and cURL:
https://www.securitylearningacademy.com/course/view.php?id=4295
(Note the video presentation is a bit out of date - for example it says no support for groups which is no longer the case).
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Tue March 23, 2021 05:50 AM
From: Joao Goncalves
Subject: MMFA Cookbook updated for Verify Access
Just in case of someone is reading this, my comments have been tested in ISVA V10.0.1
Thanks a lot for your answer, and it help clarifying somethings, but not all. So, let me ask you additional questions:
> In step 6.3 as you mention, will work, but in fact, the ACLs will only be needed much later, in section 12.4 where you create the /app junction
> You also refer in the next section "You don't *have* to pick a private key here;". Well, in fact if you don't select a keystore with a private key, when configuring, in step "7.2 - Configure SCIM", the you will not be able to select any other User DN attribute, except cn. If the user suffix is in fact uid, you will not be able to use it! Why? Does this mean that when you connect to an external LDAP you have to use cn= as the User DN attribute since there is no other option?
> Regarding IV-GROUPS, and so on, I still don't understand. I am testing the /scim endpoints using curl, but before I login using pkmslogin.form. I don't send any header to /scim/Users/Me or /scim/Users/{Id} and it works fine, and I am not sending any IV-GROUPS, and IV-USER!
Here is the curl command that I am sending and is working fine, as long as the logged in user belongs to the adminGroup.
curl -v $VERBOSE -s -k --cookie-jar cookie.jar --cookie cookie.jar \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H "Accept: text/html" \
-X GET https://$HOST/$JUNCTION/Users/$USER_ID \
--data-ascii ""
> "the "admin group" name in LDAP and the "admin group" name in AAC user registry must both match the admin group name defined in the SCIM configuration." This is completely new to me. In fact I created a group named "scimAdminGroup", and I don't have it created in the "AAC registry". What I find is that some endpoints are working fine, like /scim/Users but others are not like /scim/Groups. I will give it a try, and see if I change this it will work better. Does this mean that the scim administrator, must be also defined in the AAC user registry? I didn't see this in the cookbook?
This the curl command to retrieve the groups:
curl -v $VERBOSE -s -k --cookie-jar cookie.jar --cookie cookie.jar \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H "Accept: text/html" \
-X GET https://$HOST/$JUNCTION/Groups \
--data-ascii ""
And this is what I am getting back:
{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"SCIIS0001E
The resource 'c2NpbWFkbWluZ3JvdXA' was not found.","status":"404"}
In this case, the base64 c2NpbWFkbWluZ3JvdXA is in fact scimadmingroup, but when I created this group in embedded ldap it had the name "scimAdminGroup"! Does is mean that the group name must be in lower case only?
> As an additional topic, I wish there were some examples to test the functionality of /scim in the cookbook. I am in fact creating a set of scripts to test /scim, like to curl that I showed above, and I will post send them later to you, after everything is working.
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
Original Message:
Sent: Tue March 23, 2021 05:00 AM
From: Jon Harry
Subject: MMFA Cookbook updated for Verify Access
Hi Joao,
Let me try and answer your questions...
> In step 6.3 - setup ACLs, we're supposed to create a set of ACLs, how is this possible, if the protected resources, the demo application hasn't yet been created?
The objectspace under a WebSEAL server is "dynamic" meaning that it doesn't exist as fixed objects. You can attach ACLs (and POP, AuthznRules, extended attributes) anywhere in this objectspace. Maybe "attach" is a confusing word in this case because really you are not attaching to anything. Obviously what really matters is that the path you give when attaching is the correct path that does (or will) exist when requests are made.
> In step 7.1, When configuring an ISAM Runtime Server Connection, in the documentation you can read: "The SCIM configuration uses Verify AccessRuntime Server Connections to connect to the LDAP servers where user information is stored. ". Does this mean that the Server Connection, is used to create a client connection to LDAP (embedded Ldap in this case?), or are we proxying the LDAP server.
When using the "Verify Access Runtime" server connection, the Bind and SSL information is for connection to the primary LDAP (which is the embedded LDAP if you are using that). Bind data for other LDAP servers comes from the ldap.conf file. In fact, in some cases it is possible to configure the primary LDAP bind DN and password in the ldap.conf too - in which case you can leave the fields here empty.
> Either way, we have option to Bind to the LDAP server, which is fine, but regarding SSL configuration, we can use a key store. In this store, we MUST access to LDAP private key!!!! Why? If we are a client or proxy, we need to access the public key of the LDAP server, not its private key!
You don't *have* to pick a private key here; you are only doing so in this example because the embedded LDAP keystore is the store used by the embedded LDAP and so it also has the private key. If you prefer you could create a new keystore only containing the public key for the embedded LDAP and point at that instead.
The "SSL Mutual Authentication key" is always a private key but unless you're doing mutual authentication for LDAP access then you should leave this unset.
> When defining the /scim junction, we are supposed to select IV-USER, IV-GROUPS and IV-CREDS. In the knowledge center they just mention that this is mandatory, in this cookbook I can see we must select it, but I don't know why it is needed, where this information is used!
The SCIM service uses the IV-USER and IV-GROUPS flags to identify the "real" calling user (and their groups) when the SCIM service is being accessed via WebSEAL. If you don't send these fields then the user identified in the Basic Authentication header will be used for authorization (and for access to /Me).
> In step 7.5 we are supposed to create a group named adminGroup it would be better to use a different name as it may be confused with adminGroup that is already defined in the AAC Runtime, where easuser is already defined. In the SCIM configuration, we would then need to change the Administration group to this user (i believe that would be the right procedure)
In order for admin access to work both for direct access and for access via WebSEAL, the "admin group" name in LDAP and the "admin group" name in AAC user registry must both match the admin group name defined in the SCIM configuration. At the time of writing, I couldn't create a new admin group in AAC registry and so the LDAP group name also had to be "adminGroup". I don't know if this limitation has been fixed.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Mon March 22, 2021 01:39 PM
From: Joao Goncalves
Subject: MMFA Cookbook updated for Verify Access
I also think it is an excellent source of information, but I still trying to make it work, and I have a few questions:
- In step 6.3 - setup ACLs, we're supposed to create a set of ACLs, how is this possible, if the protected resources, the demo application hasn't yet been created?
- In step 7.1, When configuring an ISAM Runtime Server Connection, in the documentation you can read: "The SCIM configuration uses Verify AccessRuntime Server Connections to connect to the LDAP servers where user information is stored. ". Does this mean that the Server Connection, is used to create a client connection to LDAP (embedded Ldap in this case?), or are we proxying the LDAP server. Either way, we have option to Bind to the LDAP server, which is fine, but regarding SSL configuration, we can use a key store. In this store, we MUST access to LDAP private key!!!! Why? If we are a client or proxy, we need to access the public key of the LDAP server, not its private key!
- When defining the /scim junction, we are supposed to select IV-USER, IV-GROUPS and IV-CREDS. In the knowledge center they just mention that this is mandatory, in this cookbook I can see we must select it, but I don't know why it is needed, where this information is used!
- In step 7.5 we are supposed to create a group named adminGroup it would be better to use a different name as it may be confused with adminGroup that is already defined in the AAC Runtime, where easuser is already defined. In the SCIM configuration, we would then need to change the Administration group to this user (i believe that would be the right procedure)
I will update this later with more issues.
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
Original Message:
Sent: Mon August 03, 2020 05:29 AM
From: Jon Harry
Subject: MMFA Cookbook updated for Verify Access
The cookbook is now also published on the Security Learning Academy:
http://ibm.biz/Verify_Access_MMFA_cookbook
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Fri July 17, 2020 06:48 AM
From: Jon Harry
Subject: MMFA Cookbook updated for Verify Access
Hello All,
Our popular Mobile Multi-Factor Authentication (MMFA) cookbook has been updated for IBM Security Verify Access v10.0.0.
This cookbook includes step-by-step instructions (starting with Virtual Appliance installation) for setting up out-of-band transaction verification and password-less authentication. It covers topics including OAuth 2.0, SCIM, Advanced Authentication, Context-Based Access policies and more. A great way to explore many interesting capabilities of Verify Access.
Thanks to Jasmine and Sharnee from our development lab in Australia, this update includes new screenshots throughout which showcase the updated v10 admin UI.
The updated assets have been published in the original blog post:
https://community.ibm.com/community/user/security/blogs/jon-harry/2020/02/06/mobile-multi-factor-authentication-ibm-verify-mfa
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------