Авторизация с использованием shibboleth sso

Мы интегрировали shibboleth web sso в наше приложение для аутентификации пользователя. Теперь мы хотим сделать авторизацию для нашего приложения. Ниже приведен процесс, который я думаю для authz.

• Согласно shibboleth idp, пользователь, не прошедший проверку, перенаправляет на login.jsp из idp
• Как только пользователь вводит имя пользователя и пароль, страница идет в нашу базу данных и проверяет подлинность пользователя. Здесь я хочу получить разрешения для пользователя, если он аутентифицирован.
• Теперь снова пользователь перенаправляет idp с некоторой информацией вместе с разрешениями, поэтому idp перенаправляет на наш поставщик услуг с этими разрешениями, мы не можем контролировать авторизацию для пользователей. Здесь я узнал, что мне приходится иметь дело с attribute-resolver.xml, сейчас мы используем принцип и transientId в этом xml. Поэтому я знаю, что могу получить информацию requierd (Permissions) от ответа saml от shibboleth idp.

Поэтому, пожалуйста, скажите мне, как обращаться с атрибутом-resolver.xml, чтобы добавить наши разрешения для авторизации. Вопрос: Какой лучший способ сделать авторизацию с помощью shibboleth?

Пожалуйста, изучите следующий поток, который я следую за... Идентификация потока с idp, и мы пишем наш собственный SP. 1) Следующий запрос encodeSaml будет Idp следующим:

 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>

→ Как только дело доходит до вышеупомянутого пути, пользователь может видеть login.jsp, и пользователь вводит учетные данные и отправляет на наш сервер для проверки пользователя. Таким образом, мы получим логическую переменную независимо от того, действителен ли пользователь или нет.

→ Как только мы получили статус с нашего сервера, мы готовим запрос и ответ, например, следующий, который должен быть снова отправлен на idp (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) Таким образом, вы получите освобожденные необходимые атрибуты из SP (ответ SAML) и выполните дальнейшую обработку (авторизацию).