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

Question

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

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

Так что скажите, пожалуйста, как обращаться с attribute-resolver.xml, чтобы добавить наши разрешения для авторизации. Вопрос с imp: Каков лучший процесс для авторизации с использованием 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 ответа) и сделать дальнейшую обработку (авторизации).

Answer 1

Вы владеете и управляете IdP? Если нет, у вас нет доступа к attribute-resolver.xml и вы должны искать атрибуты в своей базе данных, когда ваше приложение получает основные данные.

attribute-resolver.xml как IdP получает атрибуты, которые могут иметь отношение к нескольким приложениям. Все атрибуты будут разрешены, даже если вашему приложению не разрешено получать определенный атрибут. Поэтому, если вы владеете IdP и считаете, что этот атрибут будет иметь значение, обязательно загрузите его в IdP и прочитайте его, когда ваше приложение получит ответ SAML от IdP.

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