Sun Enterprise Authentication Mechanism Handbuch

Empfangen von Berechtigungsnachweisen auf dem Server

Ein Server muß in der Lage sein, die Berechtigungsnachweise eines Clients abzurufen. Die unter Beispiel 8-5 gezeigte Funktion rpc_gss_getcred() ermöglicht es dem Server, entweder UNIX- oder RPCSEC_GSS-Berechtigungsnachweise (oder beide) zu empfangen. Dies wird über zwei Argumente erreicht, die festgelegt werden, wenn die Funktion erfolgreich durchgeführt wurde. Der eine stellt einen Zeiger auf die Struktur rpc_gss_ucred_t dar, die die UNIX-Berechtigungsnachweise des Aufrufenden enthält, wenn dieser existiert:

typedef struct {
    uid_t   uid;          /* Benutzer-ID */ 
    gid_t   gid;          /* Gruppen-ID */ 
    short   gidlen; 
    git_t   *gidlist;     /* Liste der Gruppen */ 
} rpc_gss_ucred_t;

Das andere Argument stellt einen Zeiger auf die Struktur rpc_gss_raw_cred_t dar, die wie folgt aussieht:

typedef struct { 
		u_int                  version;               /* RPCSEC_GSS-Programmversion */ 
		char                   *mechanism; 
		char                   *qop; 
		rpc_gss_principal_t    client_principal;     /* Client-Hauptbenutzername */ 
		char                   *svc_principal;       /* Server-Hauptbenutzername */ 
		rpc_gss_service_t	service;             /* privacy, integrity enum */ 
} rpc_gss_rawcred_t; 
(Eine Beschreibung der Struktur rpc_gss_principal_t und zu ihrer Erstellung finden Sie unter "Generieren von Client-Hauptbenutzernamen".) Da rpc_gss_rawcred_t sowohl die Hauptbenutzernamen für den Client als auch den Server enthält, kann rpc_gss_getcred() beide zurückgeben.

Beispiel 8-5 stellt ein Beispiel für eine einfache server-seitige dispatch-Prozedur dar, in der der Server die Berechtigungsnachweise für den Aufrufenden erhält. Die Prozedur ruft die UNIX-Berechtigungsnachweise des Aufrufenden ab und verifiziert die Identität des Benutzers mit dem Mechanismus, QOP, und dem Service-Typ, der im Argument rpc_gss_rcred_t enthalten war.


Beispiel 8-5 Abrufen von Berechtigungsnachweisen

static void server_prog(struct svc_req *rqstp, SVCXPRT *xprt) 
{ 		rpc_gss_ucred_t *ucred; 
		rpc_gss_rawcred_t *rcred;
 
 		if (rqst->rq_proq == NULLPROC) { 
			svc_sendreply(xprt, xdr_void, NULL); 
			return; 	
		} 
		/* 
		 * Alle weiteren Anfragen authentisieren 
		 */ 

 		switch (rqstp->rq_cred.oa_flavor) { 
		case RPCSEC_GSS: 
			/* 
			 * Informationen über Berechtigungsnachweis abrufen 	
			 */ 
			rpc_gss_getcred(rqstp, &rcred, &ucred, NULL); 
			/* 	
			 * verifizieren, daß der Benutzer die Zugriffserlaubnis 
			 * besitzt verwenden empfangener Sicherheitsparameter
			 * durch Einsichtnahme in meine Konfigurationsdatei 
			*/
 			if (!authenticate_user(ucred->uid, rcred->mechanism,
 				rcred->qop, rcred->service)) { 
				svcerr_weakauth(xprt); 
				return; 
			} 
			break; 	/* Benutzer zulassen in */ 
		default: 
			svcerr_weakauth(xprt); 
			return; 
		} /* Ende von switch */ 
 
		switch (rqstp->rq_proq) { 
		case SERV_PROC1:
 			. . . 	
		} 
 		/* normale Anfragenverarbeitung; Antwort senden ... */ 
 		return; 
}

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_getcred(3N).

Cookies

In Beispiel 8-5 stellt das letzte Argument für rpc_gss_getcred() (in diesem Fall NULL) einen benutzerdefinierten Cookie dar, dessen Wert bei der Rückgabe dem entspricht, was vom Server bei der Erstellung des Kontextes festgelegt wurde. Dieser Cookie, ein Wert von vier Byte, kann in beliebiger, für die Anwendung geeigneter Weise verwendet werden -- es wird nicht von RPC interpretiert. Der Cookie kann beispielweise aus einem Zeiger oder einem Index auf eine Struktur bestehen, der den Initiatior earstellt; anstatt diesen Wert für jede Anfrage zu berechnen, wird er vom Server bei der Erstellung des Kontextes berechnet (und spart somit Zeit bei der Anfrageverarbeitung).