IBM Security Verify

 View Only
Expand all | Collapse all

MMFA Cookbook updated for Verify Access

  • 1.  MMFA Cookbook updated for Verify Access

    Posted Fri July 17, 2020 06:49 AM
    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
    ------------------------------


  • 2.  RE: MMFA Cookbook updated for Verify Access

    Posted Mon August 03, 2020 05:29 AM
    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
    ------------------------------



  • 3.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue February 23, 2021 03:57 PM
    Hi Jon,

    Excelente Cookbook!  Congratulations!
    But is possible to enable MMFA per user in reverse proxy?  Some customers doesn´t want to enable for everyone.
    Does it work using AD as identity provider?

    Regards,
    Rodrigo Xavier

    ------------------------------
    Rodrigo Xavier
    ------------------------------



  • 4.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed February 24, 2021 07:04 AM
    Hi Rodrigo,

    I'm glad you liked the cookbook.

    If you want to trigger MMFA for only certain users, there are a number of ways you could do this.

    If you are triggering MMFA from a context-based access policy, you could add logic to that policy to check the user's group membership (for example) before requiring MMFA.  That way, only users in the group (or those *NOT* in the group) would be required to perform MMFA.

    In Verify Access v10 there's the concept of "branching authentication policies".  You could use a branching policy to add logic which decides whether the user should be directed down a branch that includes MMFA mechanism - or down another branch that includes a different (or no) mechanism.  Logic in the JavaScript of a branching policy could perform lookup on the user object (via UserLookupHelper or SCIM) to make decision based on any LDAP property of the user - or (for example) whether they have a registered authenticator or not.

    Use of MMFA is not dependent on user being "local"; it can work for users locally defined in LDAP or it can work on "external" users which are federated from an identity provider (such as AD/ADFS).

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 5.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed February 24, 2021 07:34 AM
    Hi Jon,

    Perfect!
    The customer wants to use MMFA in any calls to reverse proxy attempting to access backends applications.  So, in this case, which is the best practices, context based access policy or branching authentication policies?

    Thanks again!
    Rodrigo


    ------------------------------
    Rodrigo Xavier
    ------------------------------



  • 6.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed February 24, 2021 07:51 AM
    Hi Rodrigo,

    If you're planning to make MMFA part of the initial login for all access, it would probably be most efficient to use authentication levels and "step up" within the Reverse Proxy to directly trigger an authentication policy for all sessions.  In that case you wouldn't be using context-based access and so the branching policy would be more suitable I think.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 7.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed February 24, 2021 08:55 AM
    Hi Jon,

    Perfect!
    I really appreciate your help.
    Thank a lot!

    Best Regards,
    Rodrigo

    ------------------------------
    Rodrigo Xavier
    ------------------------------



  • 8.  RE: MMFA Cookbook updated for Verify Access

    Posted Mon March 22, 2021 01:40 PM
    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
    ------------------------------



  • 9.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 23, 2021 05:00 AM
    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
    ------------------------------



  • 10.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 23, 2021 05:51 AM
    Edited by Joao Goncalves Tue March 23, 2021 06:53 AM
    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.

    > Another thing. I finally managed to create a new user, but although I can find it in the /scim/Users, he is nowhere to be found in LDAP server! I thought that when someone created the user in /scim, in ISVA implementation, it would also create the user in the LDAP server! Am I missing something?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 11.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 23, 2021 06:49 AM
    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
    ------------------------------



  • 12.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 23, 2021 07:06 AM
    Edited by Joao Goncalves Tue March 23, 2021 08:08 AM
    I am still trying to use all scim APIs.

    > I finally managed to create a new user, and I can find it when using GET /scim/Users, but he is nowhere to be found in LDAP server! I thought that when someone created the user in /scim, in ISVA implementation, it would also create the user in the LDAP server! Am I missing something? It this is the default behaviour, how can the user login using pkmslogin.form?

    > When I try to delete a user, I get an error message stating that I cannot delete a user that is a GSO User! Why is this? and where in the knowledge center states this?
    I already tested the DELETE user, and it is working fine too.

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 13.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 23, 2021 11:13 AM
    I managed to figure out what was the problem /scim/Groups, but I would never be able to find it using the ISVA LMI interface. The issue was related to the LDAP users that were created there, that were not listed in the Policy Administration. There were some users that were somehow created with suffix dc=iswga that prevented to have the /scim/Groups work correctly!

    Even the /scim/demo.html was no longer working because of this issue.

    Now I am progressing to see how I can create a scim user simultaneously in the SCIM DB and it in the LDAP server.

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 14.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 23, 2021 07:57 PM
    Hi Jon,

    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 requirement has not changed. I think you are confusing direct access to the runtime and access through a WebSEAL instance. If you are accessing SCIM directly from the runtime IP, and authenticating with easuser, and expecting to perform administrator actions, then easuser will need to be in adminGroup in the AAC user registry. This does not apply when accessing SCIM via WebSEAL, as the authentication and authorization checks at the SCIM level disregard the easuser auth and instead prioritise the iv-user and iv-groups data.

    ------------------------------
    Jasmine
    ------------------------------



  • 15.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 24, 2021 05:03 AM
    Edited by Joao Goncalves Wed March 24, 2021 05:13 AM
    I just need some further details and explanation regarding this issue/requirement. In fact I don't want to use something that works, but is not supported. So I need to understand
    • I am using SCIM directly through a transparent junction /scim defined in a reverse proxy
    • The /scim junction uses localhost as the backend server, as it is using basic authentication as easuser
    • easuser is in the AAC user registry

    When configuring SCIM, in the General tab, the attribute Administration Group, is an LDAP group that is NOT adminGroup. The Group, scimAdminGroup is a "Full Group" and its only member is scimadmin.
    When I login as "scimadmin", I can execute /scim/Users, and get all users registered with the correct suffix from the LDAP server (the embedded LDAP), I can create new users successfully.

    Is there anything I am missing?

    One thing also that I found quite odd! When the configuration was not working when accessing "GET /scim/Groups", it returned an error, that, after base64 decoding, was scimadmingroup, which match the "scimAdminGroup" group that I had, but in lowercase. When I used the Apache Directory Studio, to see where this name came from, it was the "displayName" of my group! So, one of the things I had to do was to recreate the Group, so that the displayName would match the cn of the group!

    After a few more steps, finally "/scim/Groups" was working! Unfortunately, I opened a ticket in Support, and after a few days, I was given no help, to sort this out!

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 16.  RE: MMFA Cookbook updated for Verify Access

    IBM Champion
    Posted Wed March 24, 2021 06:03 PM
    Hello All,

    @Joao Goncalves do you has a configuration SCIM using basic-user-support?
    I try logon with my Active Directory user, because that i needed federated ​ as basic-user-support, on /scim/Me portal and i received a error:



    Could not retrieve user data : {"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"SCIIS0001E O recurso 'YWdhbW1hcm8' n\u00e3o foi localizado.","status":"404"}

    But, when i logon using a user registered in Verify Runtime LDAP (IBM Security Directory Server) works fine.
    What am I doing wrong?

    Regards,

    ------------------------------
    Alexandre Gammaro
    CyberSecurity Especialist
    Triscal
    ------------------------------



  • 17.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu March 25, 2021 05:23 AM
    Apparently he is looking for a user with name agammaro, Which I believe is you.
    You should go to SDS, and check the properties of agammaro user. When SCIM searches for a user (which I believe it is you), it get in touch with ldap, and does a Ldap Search. What I believe it is happening, is it can in fact contact LDAP server (your SDS), but the search returns with an error.
    I'm not sure which field he using to find you, but in Groups, I believe it is the "displayName". Check, in SDS, which is your displayName, and make sure it is equal to the uid or cn.

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 18.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu March 25, 2021 06:06 AM
    Edited by Jon Harry Thu March 25, 2021 06:10 AM
    Hi Alexandre,

    When the SCIM function does lookup for LDAP data of a user, I think it uses the LDAP attribute mapped from the "username" SCIM attribute.  I think the default for this is "uid".  So, by default, you need to make sure that the uid contains the username in all directories.

    You can change this mapping in SCIM configuration  - to point to a different attribute (samAccountName?) - but then users in SDS will fail because they don't have this attribute.

    I'm pretty sure  I've seen this issue before - I don't know if we have any fix or workaround for this case.  Ideally, for federated directories, the useranme needs to follow what is configured for username lookup in that directory in ldap.conf.  Not sure if we can do that today. @Jasmine Smith may know?

    Jon.

    Edit: Worth saying that for the MMFA function, this issue doesn't prevent it from working.  The SCIM lookups used by MMFA don't look for the LDAP user - they are only looking up MMFA data which is stored in the AAC Database so the LDAP name mapping isn't applicable.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 19.  RE: MMFA Cookbook updated for Verify Access

    IBM Champion
    Posted Thu March 25, 2021 12:52 PM
    Hi @Joao Goncalves

    Yes, you're alright, the user that was not found is agammaro (my user in federated directory - AD). In ISDS, i dont have that user.

    Hi @Jon Harry

    The "User Profile" configuration is showed bellow:

    But, I think that i havent a attribute uid on Active Directory, and the attribute sAMAccountName doesnt exist on theses lists (User DN Attribute and User ID Attribute).

    Regards,
    ​​​

    ------------------------------
    Alexandre Gammaro
    CyberSecurity Especialist
    Triscal
    ------------------------------



  • 20.  RE: MMFA Cookbook updated for Verify Access

    Posted Tue March 30, 2021 06:39 PM
    Hey Jon,

    One of our SCIM limitations is that only 1 LDAP schema can be mapped to, regardless of how the LDAP servers are configured (i.e. even for Runtime Server Connections/Federated Directories). So the SCIM mapping should be updated to match the LDAP that contains the users.

    If the ability to configure multiple sets of LDAP schema (i.e. 1 per LDAP server) is required, an RFE should be opened.

    ------------------------------
    Jasmine
    ------------------------------



  • 21.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 31, 2021 03:42 AM
    The other limitation, is you cannot extend the Attribute list that you can use to map to LDAP schemas.
    You only support the schemas:core.2.0 and Enterprise schemas. In fact there are few more, that are isam defined schema, but you cannot have user defined schemas.
    But I wonder when user can define and use their own schemas. Any plan allowing this?

    Because of this limitation, we have to do some workarounds to make scim usable in my scenario!

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 22.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 31, 2021 06:17 PM
    Every time "extend the user schema" comes up, I recommend opening an RFE. There may be an RFE already open that you could vote on (I don't have access to see voteable RFEs).

    ------------------------------
    Jasmine
    ------------------------------



  • 23.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 31, 2021 04:04 AM
    I wonder also if you want to transform an scim attribute type (e.g. string) to an LDAP attribute type (e.g. number) how you can do it.

    Or if you want to merge two attribute is scim into one ldap attribute how to do it, and vice-versa, because you not only need to save the attribute in Ldap, but you also need to retrieve the attributes.

    An example that you have to deal with is "active". In fact "active" is a boolean variable, but in LDAP we have an attribute called "status" that is not boolean, how can we do this?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 24.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu April 01, 2021 02:48 AM
    Hello Jasmine,
    good point but even worse theSCIm Schema can't be extended. You are able to map existing SCIM Attributes but can't add new ones. Another one is that you can just use one Suffix, so all your Users need to be under this Suffix. Federation within the same Server doesn't work. I've rosen an RFE on that in beginning of 2020 ....


    ------------------------------
    Jens Petersen
    ------------------------------



  • 25.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu April 01, 2021 06:01 AM
    Hi Jens:

    What do you mean by "Federation within the same Server doesn't work"?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------



  • 26.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu April 01, 2021 06:54 AM
    Well, if you e. g. got a suffix X and another one called y with both holding users you can't use SCIM for both. Trying to federate the suffixes also doesn't work as they are in the same LDAP repository. 
    Basically that are two different issues but would have been a workaround. 

    Viele Grüße 
    Jens Petersen
    Vom Mobile gesendet





  • 27.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu July 07, 2022 07:17 AM
    Hello Jens,

    I've been able to "extend" the SCIM schema by adding custom LDAP attributes under the SCIM "entitlements" attribute.  Unfortunately, multi-valued attributes can't be added this way as the IBM SCIM implementation will only write a single value.
    A multi-tenant SCIM solution isn't possible with a single server.  You'd need to set up separate servers so each could have their own SCIM configuration.
    IBM's response to my pointing these out were that this is how the SCIM standard was written ... which is true to a point.  The implementation is the bare minimum needed to be SCIM compliant but the standard allows for additional functionality (like multi-valued attribute support) even if it doesn't require it.

    -Stan

    ------------------------------
    Stan Logan
    ------------------------------



  • 28.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu July 07, 2022 07:21 PM
    Custom attributes, including multivalued ones, can be added to admin defined schemas from 10.0.3 onwards:
    https://www.ibm.com/docs/en/sva/10.0.3?topic=api-custom-schema-extensions

    ------------------------------
    Jasmine
    ------------------------------



  • 29.  RE: MMFA Cookbook updated for Verify Access

    Posted Fri July 08, 2022 11:36 AM
    Excellent!  My customer hasn't been able to upgrade due to an issue encountered when testing the /scim/Groups endpoint on 10.0.3.  Once a hotfix is provided we'll have to look at migrating from the multi-attribute solution I had to implement.

    ------------------------------
    Stan Logan
    ------------------------------



  • 30.  RE: MMFA Cookbook updated for Verify Access

    IBM Champion
    Posted Wed February 24, 2021 06:36 PM
    Hi Jon,

    Great Cookbook... i'm using it to try implement MMFA on my enviroment, but i still with the problem to configure SCIM.
    My enviroment has a ISDS as LDAP and Active Directory federated.
    When i configure "Server Connection" as Verify Access Runtime, i cant open the SCIM demo app, shows me a red bar with this message:

    Error

    Could not retrieve user data : {"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"detail":"HPDAA0333E Unable to determine the registry server type. Error message HPDAA0329E The credentials provided can not be authenticated by the registry..","status":"500"}

    Could you help me?

    Regards,

    ------------------------------
    Alexandre Gammaro
    CyberSecurity Especialist
    Triscal - agammaro@triscal.com.br
    ------------------------------



  • 31.  RE: MMFA Cookbook updated for Verify Access

    Posted Thu February 25, 2021 11:48 AM
    Hello Alexandre,

    The message appears to indicate that the BIND credentials set for the SCIM connection are incorrect.

    What kind of server connection are you using in your SCIM configuration?  In an environment that has a federated AD I think you should probably use the "ISAM Runtime" type (Rather than LDAP type).  When using the ISAM Runtime type, the bind credentials should be those for the primary LDAP (i.e. your SDS).

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 32.  RE: MMFA Cookbook updated for Verify Access

    IBM Champion
    Posted Thu February 25, 2021 04:36 PM
    Edited by Alexandre Gammaro Thu February 25, 2021 05:02 PM
    Hi Jon,

    My enviroment has a ISDS as LDAP remote and Active Directory federated.
    I was using cn=root,secAuthority=Default, but i removed the secAuthority=Default and worked fine!
    Also, i have problems with the MMFA configuration.
    I did all the steps and i cant see any pictures when i call the url to configure MMFA.


    ------------------------------
    Alexandre Gammaro
    CyberSecurity Especialist
    Triscal - agammaro@triscal.com.br
    ------------------------------



  • 33.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 03, 2021 07:55 AM

    Hi Alexandre,

    I would suspect an ACL issue which is preventing images from loading but it's impossible to tell without more information.

    As a first easy step, I would recommend loading the page with browser developer tools on so you can see the requests being made from the browser and whether they are getting good responses from Verify Access.

    Be sure to check the response content even if you see 200 response.  If a resource cannot be loaded because of an ACL, you may be getting back a login form instead of the resource requested.

    Jon.



    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 34.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 03, 2021 09:01 AM
    Hi Jon,
    I have the same issue, but only with my Firefox browser, I've already checked ACLs and are fine, any image / resource request obtains a 200 ok. With Edge and Chrome I see the images correctly....

    Ciao,
    P.

    ------------------------------
    Pietro Mosini
    IBM
    Rome
    ------------------------------



  • 35.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 03, 2021 10:22 AM
    Alexandre, Pietro,

    I have a Verify Access v10 system with MMFA set up and this manage page is working OK for me on that version in Firefox.

    I notice from Alexandre's screenshot that he is using ISAM so it's an older version.  Perhaps fixes have been made to the HTML to work-around some change in Firefox.  Not sure how to easily compare though.  What version are you using Pietro?

    If this issue is blocking you from registering MMFA authenticators, you could use this URL instead:
    .../mga/sps/mga/user/mgmt/html/device/device_selection.html

    This page has a Register Authenticator button which will also trigger MMFA authenticator registration.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 36.  RE: MMFA Cookbook updated for Verify Access

    Posted Wed March 03, 2021 10:55 AM
    Hi Jon,
    I'm using ISVA 10.0.1 and this is the result:

    Strangely, another colleague using firefox too is able to see the images correctly, so it seems to be a local problem but is difficult to understand which one...

    with the other URL, .../mga/sps/mga/user/mgmt/html/device/device_selection.html indeed it is better:

    thx,
    P.

    ------------------------------
    Pietro Mosini
    IBM
    Rome
    ------------------------------



  • 37.  RE: MMFA Cookbook updated for Verify Access

    IBM Champion
    Posted Wed March 03, 2021 01:12 PM
    Hi Jon,

    I'm using v10.0.1 and all the images has 200 status response.
    My issue happens with all browsers that i have in my machine, such as Firefox, Chrome, Edge....

    When i call the url mentioned by you (/mga/sps/mga/user/mgmt/html/device/device_selection.html), i can see this screen.


    ------------------------------
    Alexandre Gammaro
    CyberSecurity Especialist
    Triscal - agammaro@triscal.com.br
    ------------------------------



  • 38.  RE: MMFA Cookbook updated for Verify Access

    IBM Champion
    Posted Mon March 22, 2021 12:05 PM
    Hi all,

    According to the support case that i opened, this function just work in browser en-US.
    Thats alright, Jon?

    Regards,

    ------------------------------
    Alexandre Gammaro
    CyberSecurity Especialist
    Triscal
    ------------------------------