PAM에서 중요한 점은 연관 인증 모듈들이 사용자를 어떻게 인증하기로 할지에 대해 응용에서 아무것도 모르게 한다는 것이다. 그래서 응용에서 할 수 있는 건 모듈들을 대신해 사용자(클라이언트)와 직접 소통할 대화 함수를 제공하는 게 전부다.
login 프로그램에 망막 스캐너를 연결하는 경우를 생각해 보자. 이때 사용자는 "스캐너에 시선을 고정해 주세요"라는 메시지를 받게 될 것이다. 사용자명과 패스워드는 필요치 않을 것이다. 그 정보는 모두 스캔과 데이터베이스 검색으로 얻을 수 있다. 중요한 건 망막 스캐너가 "모듈"에 잘 맞는 작업이라는 점이다.
pop 데몬 프로그램이 POP 프로토콜을 염두에 두고 작성된 것이고 어느 누구도 거기에 망막 스캐너를 붙일 생각을 하지 않았겠지만 그런 데몬을 "깔끔하게" PAM스럽게 만들면 스캐너 모듈을 붙이는 게 분명 가능해지는 것도 사실이다. 중요한 건 적절한 pam_qpopper 모듈(들)을 추가해서 [경직된/구식 클라이언트들을 위해 필요할] "표준" pop 인증 프로토콜(들)을 지원하는 것이다. 하지만 일단 그렇게 popd를 재작성하고 나면 그 자리에 다른 어떤 인증 방식도 구현할 수 있게 된다.
이식된 응용을 간단히 테스트해 보기 위해 pam_permit 모듈을 집어넣고 응용에서 패스워드 입력을 요구하는지 볼 수 있다. 그렇게 설정하면 xlock은 터미널을 잠그지 못해서 스크린세이버와 다름없을 것이고 ftp는 패스워드 없이 모든 파일에 접근을 허용할 것이다. 어느 쪽도 그리 안전한 동작이 아니지만, 이를 통해 PAM이 어느 정도의 유연성을 로컬 관리자에게 제공하는지 볼 수 있다.
제대로 된 작업의 핵심은 인증 절차(패스워드 몇 회 등)에 속한 부분과 교환 프로토콜(ftpd에서 프롬프트 앞에 331 같은 숫자 붙이기 등), 그리고 응용에서 제공하는 서비스에 속한 부분을 구별하는 것이다. PAM에서 인증 "절차"를 완전히 통제해야 하며, 대화 함수에서는 사용자 프롬프트의 형태를 조정하는 것과 입력에서 응답을 추출하는 것만 다뤄야 한다.