2

I am having a hard time digging up some information on this as I believe it is still relatively new. If you implement SSO with Salesforce you have the ability to enable SAML. I have enabled SAML and have also enabled JIT with an automatically created class to support it.

Out of this newly generated class, there are two global methods that I am assuming are called upon SSO, but I do not know which one is called or how.

global User createUser(Id samlSsoProviderId, Id communityId, Id portalId,
    String federationIdentifier, Map<String, String> attributes, String assertion) {
    User u = new User();
    handleJit(true, u, samlSsoProviderId, communityId, portalId,
        federationIdentifier, attributes, assertion);
    return u;
}

global void updateUser(Id userId, Id samlSsoProviderId, Id communityId, Id portalId,
    String federationIdentifier, Map<String, String> attributes, String assertion) {
    User u = [SELECT Id, FirstName, ContactId FROM User WHERE Id=:userId];
    handleJit(false, u, samlSsoProviderId, communityId, portalId,
        federationIdentifier, attributes, assertion);
}

Does Salesforce have some backend code that interprets the SAML coming over the SSO and then calls the methods appropriately?

The reason I am asking this is because I would like to cancel a user's SSO if they do not match x fields based off of the values coming across in the SAML in the SSO. If I did not want to update a user or create a user, would I be able to add in my own global class that could be called from the SSO?

Let me know if this is unclear / does not make sense.
Thanks

3

After having the SSO setup and being able to do some testing, I have new information on how all of this works.

The goal with the project was to be able to have a second form of authentication by seeing if some data in production matches some data being sent through the SAML. If it does, let the user through. If it doesn't, do not allow the user through.

When implementing Auth.SamlJitHandler, you have to have both methods (createUser, updateUser) defined in the class. If you auto-create the RegHandler class when setting up JitHandler, then you will have many other methods. I wanted this to be custom and not handle updating/creating users, so you can actually keep the two methods and then blow out the rest of the code, except for the JitException that comes with it (it was useful).

For me, we sent the UserId through the SAML as both the federationId and the NameId.

global User createUser(Id samlSsoProviderId, Id communityId, Id portalId, String federationIdentifier, Map<String, String> attributes, String assertion) {
    // System.debug('In CreateUser');
    // User usr = authenticateUser(federationIdentifier, attributes);
    return null;
}

global void updateUser(Id userId, Id samlSsoProviderId, Id communityId, Id portalId, String federationIdentifier, Map<String, String> attributes, String assertion) {
    System.debug('In UpdateUser');
    System.debug('UserId ' + userId);
    System.debug('samlSsoProviderId ' + samlSsoProviderId);
    System.debug('communityId ' + communityId);
    System.debug('portalId ' + portalId);
    System.debug('federationIdentifier ' + federationIdentifier);

    // if(attributes.containsKey('NameID')) {
    //     System.debug('Contains the NameID in attributes');
    // }

    User usr = authenticateUser(userId, federationIdentifier, attributes);
    System.debug(usr);

    throw new JitException();
}

If you throw a new JitException(), then the user will view the OOTB Salesforce page indicating something went wrong with the SSO. BUT the user is still technically logged in, if you hack up the URL on the error page, you can still get to the community home.

Anyways, I just wanted to let everyone know that even though the JitHandler is designed to update/create users currently, you can still hack it up to do custom methods when it comes to SSO. Hope this helps.

2
  • "The goal with the project was to be able to have a second form of authentication by seeing if some data in production matches some data being sent through the SAML. If it does, let the user through. If it doesn't, do not allow the user through" - this is better accomplished with the login flows. Thanks for posting the details of your exercise, I am glad you learned how it all works. – identigral Aug 11 '15 at 1:36
  • can you let me know how paramters like string attributes,string communityid....etc` to this createuser method – devforce Mar 15 '20 at 12:03
2

How it works with JIT provisioning but without the override in ApEx handler: https://help.salesforce.com/apex/HTViewSolution?id=000181155

To do what you're looking for, grab the generated ApEx handler and fill-in the createUser method. More information and example: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_interface_Auth_SamlJitHandler.htm

2
  • I believe you are right about having to add custom code to the class that spawns automatically on the specification of Jit handling. This could be a shot in the dark, but do you have an idea of how to negate their SSO while adding apex code to the existing methods? – Tyager Aug 5 '15 at 16:50
  • By using the handler, you're taking over the provisioning sequence. If you do nothing in createUser, the User record won't be created. – identigral Aug 5 '15 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.