Authorization using shibboleth sso

Question

We have integrated shibboleth web sso into our application to authenticate the user, Now we want to do authorization for our application. The below is the process which is i am thinking for authz.

• According to shibboleth idp, the unauthenticated user is redirects to login.jsp from idp
• Once the user enters the username and password, the page is going to our database and authenticates the user is valid or not. Here i want to get the permissions for the user if he is authenticated.
• Now again user redirects to idp with some information along with the permissions, so idp redirects to our service provider with that permissions, no we can control the authorization for the users. Here i came to know that i have to deal with attribute-resolver.xml, right now we are using principle and transientId in this xml. So i know i could get the requierd info(Permissions) from saml response from shibboleth idp.

So Please tell me, how to deal with attribute-resolver.xml to add our permissions for authorization. Imp question: What is the better process to do authorization using shibboleth?

Kindly look into the following flow which i am following... Authentication flow with idp and we are writing our own SP. 1) The below encodeSaml request is going to Idp like following:

 public Pair<String,String>  getSAMLRequest(String spUrl, String consumerUrl) {
        AuthnRequest authnRequest = null;
        //String encodedSAMLRequest = null;
        Pair<String,String> encodedSAMLRequest = null;
        try {

            authnRequest = this.buildAuthnRequestObject(spUrl, consumerUrl);
            Encoder encoder = Encoder.getEncoder();
            encodedSAMLRequest = encoder.encodeAuthnRequest(authnRequest);
        } catch (MarshallingException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }

        return encodedSAMLRequest;
    }

private AuthnRequest buildAuthnRequestObject(String spUrl,
            String consumerUrl) {
        Issuer issuer = getIssuer();
        issuer.setValue(spUrl);

        DateTime issueInstant = new org.joda.time.DateTime();
        RequestedAuthnContext requestedAuthnContext = getRequestedAuthnContext();
        AuthnRequest authRequest = getAuthnRequest(issueInstant, issuer,
                consumerUrl, spUrl);

        authRequest.setRequestedAuthnContext(requestedAuthnContext);
        String systemTime = System.currentTimeMillis() + "";
        authRequest.setID("SSOIDSAMLREQ" +systemTime);              
        authRequest.setVersion(SAMLVersion.VERSION_20);
        authRequest.setAssertionConsumerServiceIndex(1);
        return authRequest;
    }

2)  First time idp redirects the user to login.jsp by using configuration which is in the handler.xml using externalAuth

 <ph:LoginHandler xsi:type="ph:ExternalAuthn"
                 externalAuthnPath="/external/login"
                 supportsForcedAuthentication="true" >
    <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>
</ph:LoginHandler>

-->Once it comes to the above mentioned path the user is able to see the login.jsp and user will enter the credentials and submitting to the our server to validate the user. So we will get the boolean variable whether the user is valid or not.

-> Once we got status from our server we are preparing the request and response like following which is to be send it to the idp again(AuthenticationEngine.returnToAuthenticationEngine(req,resp)).

request.setAttribute(globalStrings.getForceAuthn(), false);
                Principal principal = new UsernamePrincipal(login.getAttributes());
                Subject subj = new Subject();
                subj.getPrincipals().add(principal);
                request.setAttribute(LoginHandler.PRINCIPAL_KEY, principal);
                request.setAttribute(LoginHandler.PRINCIPAL_NAME_KEY, personId);
                request.setAttribute(LoginHandler.SUBJECT_KEY, subj);
                request.setAttribute(globalStrings.getAuthnMethod(), this.authenticationMethod);
                AuthenticationEngine.returnToAuthenticationEngine(request, response);

3) We mention in the attribute-resolver and attribute-filter for the attributes to be released to the SP like below

<resolver:AttributeDefinition id="principal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">

   <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" />

        <resolver:AttributeEncoder xsi:type="SAML2Base64" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                name="ORG_ATTRIBUTE_64" />
  <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                name="ORG_ATTRIBUTE" />
</resolver:AttributeDefinition> 

4) So will get the released required attributes from the SP(SAML response) and do further processing(authorization).

Answer 1

Do you own and operate the IdP? If not, you don't have access to attribute-resolver.xml and must lookup attributes in your database when your application receives the principal data.

attribute-resolver.xml is how the IdP gets attributes that may be relevant to multiple applications. All attributes will be resolved even if your application is not allowed to receive a particular attribute. So if you do own the IdP, and think this attribute will be relevant, by all means, load it in the IdP and read it out when your application receives a SAML response from the IdP.

This is all a matter of design, and different designs will be better for different use cases. Also, the more complex the permissions data, the more likely your app should handle it.